Timeline for I've been told that Exceptions should only be used in exceptional cases. How do I know if my case is exceptional?
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 16, 2016 at 9:00 | comment | added | gnasher729 | @DanielKaplan: If interested in other languages, the rule in Objective-C is "Exceptions are for catching programming errors". So there is no need to catch exceptions and handle them at all; they are handled by fixing the code. | |
| Apr 23, 2015 at 4:09 | comment | added | Winston Ewert | @supercat, fair enough, incorporating the exception logic in a loop context would be considerably more awkward. | |
| Apr 22, 2015 at 14:47 | comment | added | supercat |
...but the catch block allows the loop to run another iteration (hopefully not indefinitely). It's much cleaner to have the requested operation yield a condition which can control loop iteration directly.
|
|
| Apr 22, 2015 at 14:45 | comment | added | supercat | @WinstonEwert: My point was that in many cases the right alternative is to provide means of issuing both "Do X" and "Try to do X" requests, with the former throwing an exception if it couldn't do X, and the latter only throwing an exception if it couldn't make the expected attempt. The former should be no less convenient than the latter, but the latter should not be excessively inconvenient. In situations where a caller might wish to retry an action in a loop (possibly with different parameters) it's rather awkward to have a loop around a try/catch block where success exits the loop... | |
| Apr 22, 2015 at 5:13 | comment | added | Winston Ewert | @supercat, why? What is so bad about having to catch an exception that you'd risk silent failures instead of having to catch them? But I'll agree that in many cases the ideal is to have an exception-less alternative. | |
| Apr 21, 2015 at 12:36 | comment | added | supercat | @WinstonEwert: If 99% of callers are going to be expecting to handle the condition, they shouldn't have to catch an exception. Actually, I'd say that if more than about 10-25% of callers will expect to handle a condition it should be possible to do so without having to catch an exception, and if more than about 10-25% will not be prepared to immediately handle it, it should be possible to request that an exception be thrown in case of trouble. In many cases, the right approach will be to have methods to perform actions either way. | |
| Apr 21, 2015 at 4:34 | comment | added | Winston Ewert | @supercat, I don't think it really matters which ends up being more common. I think the critical question is having a sane default. If I don't explicitly handle the error condition, does my code pretend nothing happened, or do I get a useful error message? | |
| Apr 20, 2015 at 19:09 | comment | added | supercat |
@WinstonEwert: If a function caller will need to handle a situation without breaking its main program flow, throwing an exception for such a situation will require the caller to add a fair amount of try/catch code. If the caller won't be able to do anything useful in that situation except throw an exception to its caller, not throwing an exception will mean the calling code has to add an if statement to check for success. Which type of call will end up being more common might be a matter of some guesswork, but it's an objective measure.
|
|
| Nov 21, 2013 at 5:58 | comment | added | Winston Ewert | @mikera, yes a function should (only) throw the exceptions defined in its contract. But that's not the question. The question is how you decide what that contract should be. I maintain that the rule of thumb, "exceptions should be exceptional" isn't helpful in making that decision. | |
| Oct 21, 2013 at 6:05 | comment | added | mikera | "Expected" is defined by not by subjective argument or convention but by the contract of the API/function (this might be explicit, but is often just implied). Different functions / APIs / subsystems can have different expectations, e.g. for some higher level functionality a non-existing file is an expected case for it to handle (it might report this to a user via a GUI), for other lower level functions it is probably not (and hence should throw an exception). This answer seems to miss that important point.... | |
| Jan 24, 2013 at 22:51 | comment | added | Andres F. |
+1 "exceptions should be exceptional" is a terrible rule of thumb. Well said! That's one of those things people just repeat without thinking about them.
|
|
| Jan 24, 2013 at 18:47 | comment | added | Daniel Kaplan | @gnat It's tagged java because I thought the context could be useful, but I am still interested in answers related to other languages. | |
| Jan 24, 2013 at 15:18 | comment | added | Winston Ewert | @gnat, I know. My point was that you should follow the conventions of the language (in this case Java) even if they aren't your favorite. | |
| Jan 24, 2013 at 15:01 | comment | added | gnat | "Different languages..." - by the way this question is tagged java | |
| Jan 24, 2013 at 14:57 | history | answered | Winston Ewert | CC BY-SA 3.0 |