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
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 29, 2021 at 7:49 | comment | added | cskwg | Exceptions make troubleshooting harder, in development and production, on server and client. As a developer, one should always turn on "Break on unhandled exceptions", in JavaScript and C#, for example. But when the code throws lots of exceptions, you have to turn this off. And then you will then miss important exceptions. The same is true for postmortem dump debugging. When there are lots of exceptions, it becomes difficult to find important ones. In earlier versions of .NET, there was a performance hit, but this is nowadays negligible. | |
| Oct 23, 2014 at 12:11 | comment | added | Doval | @v.oddou It's not clear to me that "being forced to reflect on the state of affairs" at the expense of readability is a desirable trade-off in every case. Also consider that in many cases, the error code is the return value and the "true" output of the function is a side effect; there's nothing forcing you to check the return value for errors, so you're not truly forced to consider the state of affairs. It's less of an issue in functional languages where the boilerplate of repeated error checking can be hidden with some clever high-order functions. | |
| Oct 23, 2014 at 3:35 | comment | added | v.oddou | @Doval : When you wrote your explanation, you must have realized afterward that it was a good thing to be forced to write checking code at intermediate levels. This way you are forced to reflect on the state of affairs of your function at this level. If RAII is lacking, you may then execute some steps to leave the function in a clean status, and cascade the error. | |
| Jun 24, 2014 at 15:16 | comment | added | Pacerier | @KarlBielefeldt, You claim that exceptions "simplify the code", but Mike's answer seems to directly contradict that programmers.stackexchange.com/a/184714/24257 . What are your thoughts on that? | |
| Mar 25, 2014 at 19:52 | comment | added | Doval | @Brendan Suppose some exception occurs, and the error-handling code is 4 levels below in the call stack. If you use an error code, all 4 functions above the handler need to have the error code's type as their return value, and you have to do a chain of if (foo() == ERROR) { return ERROR; } else { // continue } at every level. If you throw an unchecked exception, there's no noisy and redundant "if error return error". Also, if you're passing functions as arguments, using an error code may change the function signature to an incompatible type, even though the error may not occur. | |
| Nov 19, 2013 at 10:08 | comment | added | Brendan | The problem is that exceptions break the normal flow of control and make code harder to read/follow (e.g. trying to get where the catcher might be is far worse than "goto"). They don't simplify code at all, and only reduce the amount of typing needed for "intermediate" code (functions/methods between the catcher and the thrower). | |
| Jan 25, 2013 at 19:52 | comment | added | Evan Plaice | +1 The number spinner is an especially useful example. For the Op's specific case, UI feedback would be the best approach for an invalid or unmatched input. An exception would be used of, for instance, the wrong type (ex an integer instead of a string) is encountered. | |
| Jan 25, 2013 at 15:56 | comment | added | SoylentGray | Id say that the fact that exception handling is not as high in overhead is not reason to indugle sloppy code, or to neglect to code for expected values and check for nulls | |
| Jan 25, 2013 at 7:58 | comment | added | Leo | +1: Exactly what I was going to answer. Use it when it simplifies the code. Exceptions can give much clearer code where you do not have to bother checking return values on every level in the call-stack. (Like everything else though, if used the wrong way it can make your code a horrible mess.) | |
| Jan 24, 2013 at 21:42 | comment | added | Ingo | @RobertHarvey The trick in Java is to throw pre-fabricated exception objects, rather than throw new .... Or, throw custom exceptions, where fillInStackTrace() is overwritten. Then you shouldn't notice any performance degradations, not to speak of hits. | |
| Jan 24, 2013 at 21:08 | vote | accept | Daniel Kaplan | ||
| Jan 24, 2013 at 17:38 | comment | added | Karl Bielefeldt | I'm not saying there aren't still cases where the performance hit is a valid reason, but those cases are the exception (pun intended) rather than the rule. | |
| Jan 24, 2013 at 17:22 | comment | added | Robert Harvey | Nice swipe, there. Actually, in the real-world app I designed, the performance hit did make a difference, and I had to change it to not throw exceptions for certain parsing operations. | |
| Jan 24, 2013 at 17:18 | history | answered | Karl Bielefeldt | CC BY-SA 3.0 |