The Java Specialists wrote a post about Exceptions in Java, and in it they list a few "best practices" for creating Exceptions, summarized below:
Don't Write Own Exceptions (there are lots of useful Exceptions that are already part of the Java API)
Write Useful Exceptions (if you have to write your own Exceptions, make sure they provide useful information about the problem that occurred)
The Java Specialists wrote a post about Exceptions in Java, and in it they list a few "best practices" for creating Exceptions, summarized below:
Don't Write Own Exceptions (there are lots of useful Exceptions that are already part of the Java API)
Write Useful Exceptions (if you have to write your own Exceptions, make sure they provide useful information about the problem that occurred)
Don't do what the developers at my company did. Somebody created an [sic] InvalidArguementException that parallels java.lang.IllegalArgumentException, and we now use it in (literally) hundreds of classes. Both indicate that a method has been passed an illegal or inappropriate argument. Talk about a waste...
Joshua Bloch covers this in Effective Java Programming Language Guide [my bible of first resort on Best Practices] Chapter 8. Exceptions Item 42: Favor the use of standard exceptions. Here's a bit of what he says,
Reusing preexisting exceptions has several benefits. Chief among these, it makes your API easier to learn and use because it matches established conventions with which programmers are already familiar [my emphasis, not Bloch's]. A close second is that programs using your API are easier to read because they aren't cluttered with unfamiliar exceptions. Finally, fewer exception classes mean a smaller memory footprint and less time spent loading classes.
The most commonly reused exception is IllegalArgumentException. This is generally the exception to throw when the caller passes in an argument whose value is inappropriate. For example, this would be the exception to throw if the caller passed a negative number in a parameter representing the number of times some action were to be repeated.
That said, you should never throw Exception itself. Java has a well-chosen, diverse and well-targeted bunch of built-in exceptions that cover most situations AND describe the exception that occurred well enough so that you can remedy the cause.
Be friendly to the programmers who have to maintain your code in the future.
Videos
Like many things in programming, using custom exceptions is good if done for the right reasons and in the right situations.
If a built-in exception can acurrately describe the situation at hand, use it. E.g. FileNotFoundException, TimeoutException, KeyNotFoundException, etc.
If non of the built-in exception classes describe the situation, then you should make your own. If custom exceptions were bad, the built-in classes would be sealed or final or similar. However, don't go nuts. Just like with classes, a given exception type should probably be thrown from more than one place, otherwise it is likely unnecessarily specific.
However, a better rule of the thumb for whether to have custom exceptions is to consider what the caller will do about it when the exception gets thrown. If you have three erroneous situations that are handled in three very different ways, it makes sense to have three types because then the caller can have three catch blocks accordingly. The alternative, which is to inspect the message or data to decide what to do, is more complicated and thus more prone to error.
If all three situations instead are handled identically, it may not be worth the hassle of additional types, when just using the exception message should be enough to diagnose what the situation is. I've had to deal with many situations where a function can throw a dozen different exception types, but that to me as the caller, have inconsequential differences, so laziness kicks in and I just catch {} without the exception type and feel a little guilty about it. Don't cause that to happen.
As for one of the claims you wrote:
catching exceptions is performance hurting.
While that is true, there is virtually no difference between having custom exceptions that are caught and thrown vs just using ApplicationException for everything and making decisions based on the exception message. However, the for former situation, it is considerably easier for us humans to reason about what is happening during program execution.
There's one thing I see in the existing answers that bothers me:
Catching custom exceptions might be code smell.
If you are creating custom exceptions, you shouldn't be catching them. Exceptions are for when things go horribly wrong and recovery is impossible. Exceptions that can be handled are either your own fault or vexing.
Taking from the MSDN article Vexing Exceptions:
I first classify every exception I might catch into one of four buckets which I label fatal, boneheaded, vexing and exogenous.
Fatal exceptions are not your fault, you cannot prevent them, and you cannot sensibly clean up from them.
Boneheaded exceptions are your own darn fault, you could have prevented them and therefore they are bugs in your code.
Vexing exceptions are the result of unfortunate design decisions.
And finally, exogenous exceptions appear to be somewhat like vexing exceptions except that they are not the result of unfortunate design choices. Rather, they are the result of untidy external realities impinging upon your beautiful, crisp program logic.
I recommend reading the whole post.
Any design that creates vexing exceptions is a bad design. You (and anyone else writing code against your api) has to catch them, and doing so is vexing: so avoid creating new vexing exceptions.
Custom exception types should either be exogenous ("I'm sorry, Dave, but the database went offline")--and most of these kinds of exceptions have already been written--or Fatal and you should never handle fatal exceptions.
This last point is not adequately presented in the other answers. A bad credit card number is a validation error not an exception. Errors are communicated to the user because they can fix it. Exceptions are things the user can never do anything about. Exogenous exceptions are the exception here, as they are the fault of the world at large and the user needs to be aware of them, even if they can't fix it (but sometimes they can: Internet is disabled, the disk was ejected, the information was wrong. Regardless, there is nothing you as the developer can do to fix it: catch, display, don't crash).
A FamilyNameException is boneheaded: your code had a bug in it. Do not create boneheaded exceptions, do not handle them, write your code correctly in the first place so that these do not occur. Custom exception types are inappropriate for this reason.
A LoginException is either exogenous (the database is offline) or PEBKAC. If it is a PEBKAC error, it isn't an exception. If it is exogenous, why is the existing exception type not sufficient? There may be cases where custom exception types are relevant, but be sure to communicate properly! For example I wrote some code that communicated with an external service, which took time. My coworker was trying to ask my code for the results before the request had time to return, so my code had to generate an exception. However, he took this exception (which was boneheaded in nature) and treated it like a vexing: caught the error and assumed all zeros, thereby introducing a bug: the data retrieved from the external service was wrong! (No, the data was right, but he wasn't displaying the retrieved data and blamed my code). I ended up having to fix his code twice (he removed my first fix about 2 weeks after I added it).
To sum up:
- Catching any fatal or boneheaded exception is code smell.
- A custom vexing exception class is code smell. See also: How to avoid vexing exceptions.
- Be careful with custom exogenous exceptions: they are either redundant or can be mistaken for vexing exceptions.
On my team, we mostly use the built-in Java exceptions with a top level try-catch that logs and alerts us.
You probably see where this is going.. we get alerted for every single exception, and many of these are not actionable by us (user errors).
We now have a filter layer that filters out alerts that match a regex, so we aren’t alerted for everything now but it’s still not ideal.
I want a way to distinguish between exceptions we need to be alerted on and exceptions that can just be warnings.
I see 2 main approaches:
An AlertException class that we subclass and throw. We catch these at the top level and alert accordingly.
Some sort of Alertable marker interface that we throw and do an instance of check on. One variant is the interface could also have a method like “responseType” that returns an enum with values like: Alert Oncall, Warn, Alert user
I’m leaning towards approach 2 but would love to hear your ideas! Thanks!