I would at the very least define your own exception base type so that every exception that your code throws is an instance of that type. Depending on how many systems/modules/libraries your systems consists of, perhaps you need more than one base type. If you're interested in differences in meaning between various instances of your base type exception then I recommend creating different subclasses, but I would try to make those meaningful in the sense that they should convey what sort of error they're signalling. We now have a filter layer that filters out alerts that match a regex This you should not be doing. The information you need to make these decisions should be communicated either via structured fields (enums, booleans, etc) or the exception type. An AlertException class that we subclass and throw This I would definitely not do. The whole point of exceptions is that in your code when something bad happens you can package up information about the problem and throw it up the stack so that higher-level code which knows what the context is can handle the problem. Because what the correct error handling is depends on context. If you have a class like this then basically every time you throw an exception you have to make this alert/not alert decision, but you don't want those decisions spread all over the codebase. You also don't necessarily know everywhere in the codebase whether this is alertable or not. Instead, make the code communicate what sort of error has happened, and then have the decisions at higher levels. Personally, I think it sounds odd to do alerting on individual exceptions instead of using metrics and defining alerts on those. Note that this is all generic advice, because you said nothing about what sort of application this is. Answer from larsga on reddit.com