StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I generally find that obsessing over checked exceptions is overkill. Exceptions should be reserved for unexpected error conditions from which the program cannot reasonably recover. For these, I tend to agree with what you've observed, that special error types tend to lose their meaning.</p> <p>As a general rule, throw an exception when all of the following are true:</p> <ul> <li>The condition can't be recovered from here.</li> <li>The caller can't reasonably be expected to recover from this condition.</li> <li>Somebody will want to debug the situation, so they might want to see the stack trace.</li> </ul> <p>You'll find that if all of those are true, the type of the exception is not important, and you may as well throw java.lang.Error. If any of them are false, then an exception is probably overkill (do you really need the type, message, and stack trace?)</p> <p>Instead, consider augmenting the return type of methods to indicate expected kinds of failure. For example, use an <a href="http://functionaljava.googlecode.com/svn/artifacts/2.17/javadoc/fj/data/Option.html" rel="nofollow noreferrer">Option<A></a> type for methods where it may make sense to return no value in some cases. Use an <a href="http://functionaljava.googlecode.com/svn/artifacts/2.17/javadoc/fj/data/Either.html" rel="nofollow noreferrer">Either<A,B></a> type for methods where you might need to return a value whose type depends on failure or success. Where you might have had specialised Exception subtypes before, you can instead just use Either<Fail,A> where Fail is just an enum over the kinds of failures that are expected.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload