API Design Myth: Exceptions are for "Exceptional Errors"
I was updating FDG section on exceptions. I added one anntation that I thought I would post here as well:
KRZYSZTOF CWALINA One of the biggest misconceptions about exceptions is that they are for “exceptional conditions.” The reality is that they are for communicating error conditions. From a framework design perspective, there is no such thing as an “exceptional condition”. Whether a condition is exceptional or not depends on the context of usage, --- but reusable libraries rarely know how they will be used. For example, OutOfMemoryException might be exceptional for a simple data entry application; it’s not so exceptional for applications doing their own memory management (e.g. SQL server). In other words, one man’s exceptional condition is another man’s chronic condition. |
Comments
Anonymous
July 17, 2008
PingBack from http://blog.a-foton.ru/2008/07/api-design-myth-exceptions-are-for-exceptional-errors/Anonymous
July 17, 2008
Great explanation and I am looking forward to the second edition of the Framework Design Guidelines book. Thanks for everything you have done! On a side note, I think you fat fingered From in the following sentence. Form a framework designed perspective, there is no such thing as an “exceptional condition”. KevinAnonymous
July 17, 2008
It looks like you misspelled "from" as "form".Anonymous
July 17, 2008
Should .. "Form a framework designed perspective" Be "From a framework designed perspective" Form to FromAnonymous
July 17, 2008
Thanks! i fixed the typo.Anonymous
July 17, 2008
Maybe you should tell the CLR team as well ;-) Reflection performance on the CLR is pretty embarassing compared with other managed runtimes (see the link on my name).Anonymous
July 17, 2008
Hey Krzysztof, the From sentence should also read: from a framework design perspective. Looking forward to the next book!Anonymous
July 17, 2008
I completely agree: exception are not exceptional at all! I like to split exceptions into 3 kinds: business/asynchronous/bug Once you defined the kind of an exception, it is much easier to decide what to code to handle it. http://www.codeproject.com/KB/books/guidelines_exception_cs.aspx Looking forward FDG v2!Anonymous
July 18, 2008
Luke, thanks! I fixed that too. Patrick, I think this is exactly what I already added to FDG. I just call the three kinds of errors: usage errors, program errors, and system failures.Anonymous
July 18, 2008
Jeroen, thanks for writing the post and pushing on the CLR team. I am doing the same thing -- slowly :-)Anonymous
July 18, 2008
I have to admit that I've never really found a set of rules about how to use exceptions that I am completely comfortable with. One guideline I have tried to follow is "Exceptions should be exceptional for the function that throws them". Of course you can't know what context you're being used in, but you do know what you're intended to do.Anonymous
July 26, 2008
Czesc Krzysztof! I like your annotation. I think you touched the hotspot here. As the definition of what condition is exceptional indeed remains in the eyes of the beholder. Therefore if a subsystem is a class library one would expect many exceptions to propagate out -> hard to define what is critical and what should be handled == the usage context unknown. Service subsystem, would interpret exceptions thrown by libraries, translating them into more relevant business error hierarchy -> clear boundary defining specified usage context, now we know what is a system failure and what is a contingency error. Some more on failures / contingencies from Java universe: http://dev2dev.bea.com/pub/a/2006/11/effective-exceptions.html?page=1Anonymous
July 27, 2008
Whether something is exceptional may depend on the context, but the very same is true for the "error condition". If a file is not found, this may be an error in one context, but a totally legal thing in another. So IMHO just exchanging the term "exception" with "error" does not really make it clearer when to use exceptions and when not. The usual justification for the guideline "use exceptions only in exceptional cases" is the performance penalty you get when a lot of exceptions are thrown, meaning it is motivated rather by the idiosyncrasies of the current CLR implementation than by design principles. And in fact, currently you cannot afford a low-level function that is called thousands of times during a mass operation and throws exceptions because it detects errors for the items it processes. In our project, the guideline is to use exceptions only if a programming error has been detected, and use error return information in other cases, especially in general-purpose functions that may be called frequently and from different contexts. I think it would be a good idea to improve the exception handling speed of .NET, so exceptions can be discussed independently of performance issues.Anonymous
August 03, 2008
I agree with Michael. I much prefer programming with exceptions compared to error codes, due to the ability of exceptions to automatically propagate up the call stack, as well as the ability to pass along extra information. But currently there are too many cases where performance has to be considered.Anonymous
August 04, 2008
I'm fully in sync. with this way of thinking. People unfortunately seems too afraid of the monster of Exceptions as somehing of a big bad wolf.. Use them for the intended purpose - to communicate that the (server) was not able to fullfil the request made to it...Anonymous
August 08, 2008
The comment has been removedAnonymous
August 11, 2008
Hi, one argument is also that Exceptions not onlay are slower (in Java they are not really slow) , but that they also have somehow the same effect as goto's. As we all know since Pascal, goto's are to be avoided and therefore the same is true for exceptions :) Regards, MarkusAnonymous
March 22, 2012
Sorry Markus, but I don't follow the logic in your last sentence.