Vexing exceptions

re: Vexing exceptions

Dean Harding — Thu, 11 Sep 2008 05:03:25 GMT

About that TryParse thing, something that's bothered me is that while there's Int32.TryParse (etc), there's no Enum.TryParse. Is there any reason for that? Enum.Parse is something I do on occasion, and it's, ehem, vexing that I have to do it in a try/catch...

re: Vexing exceptions

Thu, 11 Sep 2008 05:32:38 GMT

The problem with the exogenous exceptions is that it's very hard to figure out the full list of ones you need to catch. For example, try coming up with the full list of exceptions that could possibly be thrown when you open a file. In addition to all the usual "file not found, directory not found, access denied, etc" messages you have to handle weirder cases, like the file being on a UNC share, the file being on an overlong junction, the file being pulled from a shadow copy, the file being served from a local directory that is actually a redirected folder, the file existing on a removable drive, the file living on a fake drive that is really a redirect to a URL, etc.

Coming up with that full list of exceptions is really hard. But if you miss one, your app crashes. So, of course, you catch (Exception) and handle it with a generic "that didn't work" message. But now you're committing the "sin" of "catch (Exception)".

re: Vexing exceptions

KooKiz — Thu, 11 Sep 2008 10:26:24 GMT

The "do not catch fatal exceptions" need to be clarified a bit. I agree that you probably cannot do anything to recover from the error, but you can at least do some logging stuff. I guess you consider in this article that "catching an exception" and "Logging some stuff in a catch block" are two differents concepts.

re: Vexing exceptions

Inigo — Thu, 11 Sep 2008 11:52:18 GMT

Interesting classification. From a Java perspective, I'd say:

Fatal exceptions are Errors (i.e. unchecked, and typically not caught)

Boneheaded exceptions are typically RuntimeExceptions (i.e. unchecked)

Exogenous exceptions are the reason for checked exceptions

Vexing exceptions are the reason people complain about checked exceptions

The relative frequencies of Exogenous vs Vexing exceptions in the language's libraries could determine whether checked exceptions are a good idea for that language or not.

re: Vexing exceptions

Doug — Thu, 11 Sep 2008 12:14:23 GMT

This is an excellent top-level taxonomy for exceptions. My biggest general complaint about the .NET framework is that the framework's exception hierarchy is completely useless. The hierarchy really should have been broken into something like what you describe (though Vexing and Exogenous can't truly be split via the type system). Instead of ApplicationException and SystemException, we should have had something like System.FatalException or System.DangerousException (parent class of StackOverflow, ExecutionEngine, AccessViolation, etc., the ones that should basically never be caught), System.BoneheadException or System.CodeErrorException (parent class of Argument, NullReference, or IndexOutOfBounds, etc., the ones that should immediately trigger a bug report), and System.RuntimeException (parent class of most other exceptions, the ones that might indicate a runtime failure but might also indicate a bug or a design flaw).

re: Vexing exceptions

Matt — Thu, 11 Sep 2008 12:17:17 GMT

XmlSerialization => FormatExceptions left right and center.

Defininitely in the Vexing section if you're trying to debug a specific formatting problem in it since lots of perfectly valid stuff is dealt with by catching the FormatExceptions.

re: Vexing exceptions

[ICR] — Thu, 11 Sep 2008 12:20:32 GMT

While it doesn't catch all of them, you can catch IOException to get a lot of them.

I've always thought that while having the explicitness of Java's checked and unchecked exceptions (having to explicitly say what it throws) is bad, it would have been nice to have a distinction between fatal and non-fatal exceptions (a different base class). That way you can catch non-fatal exceptions for things like logging while letting fatal exceptions through.

re: Vexing exceptions

Matt — Thu, 11 Sep 2008 12:27:00 GMT

Sorry Doug I disagree. they type hierachy is a very blunt tool which shouldn't be used for this purpose.

If you are catching an exception you either want ***really*** specific. So your response can be well defined (FileNotFound, Autorization, specific IO exceptions mainly[1]).

If you're catching anything else it is solely note the occurrence (optionally increasing the amount of information available) and rethrow or handle a domain transition (between app domains or to create your own specific exit code for a process) as such Catching Exception is fine

Anything else is almost certainly a BadIdea

[1] something the could definitely be improved, If I open a stream I'd like to know the difference between a file being locked verses a file being read only verses not being there etc...

re: Vexing exceptions

Ollie Riches — Thu, 11 Sep 2008 13:22:55 GMT

'Writing good error handling code is hard in any language'

Absolutely! thats why I think more effort should have been put into the exception strategy for .Net.

Yes the idea of 'checked exceptions' in java seems a good idea in theory but in practice it can get out of hand and I can understand why this wasn't implemented in .Net. I can also see there were ideas that all user (dev = me) exceptions should have been derived from system.application and therefore easy to handle but that idea broke down very quickly. I don't understand why the exceptions aren't grouped\segregated along the lines of namespaces - it would be nice to be able to catch just one exception type for all user related file exceptions - invalid path, invalid filename, permissions etc.

I would love the ability to do this in a 'contract first approach' - be able to define on an interface the exception types that can be generated by the implementation, then at compile time this constraint could be checked and verified.

Anyway great post cos I'm in the middle of trying to sort kinda thing out :)

re: Vexing exceptions

MiB — Thu, 11 Sep 2008 15:31:52 GMT

2 Dean Harding

You can use Enum.IsDefined for checking and then safely call Parse.

re: Vexing exceptions

Randolpho — Thu, 11 Sep 2008 17:42:42 GMT

Eric wrote this:

"Just let your "finally" blocks run and hope for the best."

Keep in mind that there are times when a finally block will *not* run, and they're almost always during Fatal exceptions.

What can we do about it? Don't put "hast to be run" code in your finally block -- only use finally for resource de-allocation.

re: Vexing exceptions

Michael Urman — Thu, 11 Sep 2008 18:10:36 GMT

In the try/catch case, the catch covers all the processing that occurs within the using block. To avoid this you have to manually code a try/catch Dispose, as using cannot be attached to an already assigned variable. Both of these options smell bad. Is there a trick that can get you the best of both - limited scope on the FileNotFoundException, and the syntactic support of the using block?

re: Vexing exceptions

Eric Lippert — Thu, 11 Sep 2008 18:26:48 GMT

> as using cannot be attached to an already assigned variable

Why do you say that?

re: Vexing exceptions

Michael Urman — Thu, 11 Sep 2008 18:55:33 GMT

Perhaps I'm mistaken? I just tested this in VS2008 and VS2005 and it works, so my memory is foggy. More likely I hit the 'Use of unassigned variable' error case if you don't have the throw or return in the sequence below.

The sequence of Declare mydisposable / try { assign mydisposable } catch { throw or return } / using (mydisposable) { } is a little clunky, but not half as bad as without being able to use using that way. Thanks!

re: Vexing exceptions

Tony Cox — Thu, 11 Sep 2008 19:13:42 GMT

Is there another category of exceptions, which perhaps I would term "internal exceptions"? (Perhaps this is really just a subcategory of exogenous exceptions?)

What I mean by "internal exceptions" is exceptions you throw and catch internally to a single component because doing so makes your program structurally more readable and maintainable, but that you do not (necessarily) intend to let fly out of your component to an external consumer.

For example, suppose you have a component which parses some sort of fairly complex data file. Structurally, let's say it's convenient to write your parser in a recursive fashion, burrowing top-down through the file as it encounters elements to parse. However, errors of various kinds could be detected at any one of many levels of this parsing process, including all the way down at a leaf node. Let's say it's okay to stop trying to parse the rest of the file when you encounter the first error. How do you report these errors back up to the caller?

You could use the traditional error code reporting method, bubbling back up a return code at each level of parsing, but that adds a lot of boilerplate error passing code to every level. It's also not terribly easy to elegantly attach additional information to the error. So instead, I think a perfectly reasonable pattern is to throw exceptions where errors occur, and then catch them all at the top-level method of the parser. You can then decide how to report this to the caller (maybe letting them handle the exception instead is okay, or maybe you want to use another method).

It's an exogenous exception in that the root cause is something not under your control (the input file, which came from elsewhere), but you threw the exception yourself because it was a convenient way to structure your code.

re: Vexing exceptions

Bryan Watts — Thu, 11 Sep 2008 20:09:48 GMT

"...but you threw the exception yourself because it was a convenient way to structure your code."

Expection handling!

Exception wisdom

Ramblings — Thu, 11 Sep 2008 20:26:36 GMT

It's pretty rare that I do straight-up trackbacks into other people's blogs, but the latest post by Eric Lippert really deserves it. He discusses the four different classes of exceptions very eloquently. While he's talking about .NET, the same truths..

Vexing exceptions

DotNetKicks.com — Fri, 12 Sep 2008 05:29:58 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com

re: Vexing exceptions

swythan — Fri, 12 Sep 2008 14:19:03 GMT

I attended a session by Jason Clark, who claimed to have worked on defining the exception strategy for the BCL (in v1.0?). He said the rule was:

* The method name MUST be (contain?) a verb describing the effect of the function.

* If that effect does not completely occur, the method MUST throw an exception.

Thus double.Parse(string) throws an exception if it does not parse the string.

Also:

* If there are common causes of failure, ways SHOULD be provided to check if it will fail before calling the function (as far as possible).

E.g. : Enum.IsDefined, File.Exists

This isn't always provided, and can't always be bullet-proof (e.g. File.Exists, as described earlier) but helps avoid many common exceptions.

IF there is a very common failure scenario where using exception handling causes a (measurable) performance degradation, then there's another set of rules:

* Add another function that handles that error condition and JUST that error condition by returning e.g. false.

* The new function MUST have a name that reflects the fact that it might not succeed.

Thus: bool double.TryParse(string) which will, of course, throw exceptions if it hits any failure other than a badly formatted string (e.g. OutOfMemoryException).

He also said that the reason that CLR exceptions are slow is that they are built on top of Win32 SEH. The CLR team apparently told him there was no reason they HAD to be built on top of SEH, it was just easier. They apparently said that if the speed of exceptions ever got into (e.g) the top 10 performance issues seen in real applications, they would probably re-implement them to be faster. The implication, of course, is that they're along way outside the top 10 right now! :-)

re: Vexing exceptions

Philip Fitzsimons — Fri, 12 Sep 2008 18:32:14 GMT

hmm, interesting idea - how would we implement this?

public class LippertException: Exception, ISerializable;

public class FatalLippertException: LippertException;

public class BoneheadedLippertException: LippertException;

public class VexingLippertException: LippertException; /* or fom bonehead? */

public class ExogenousLippertException: VexingLippertException;

maybe? ;-)

re: Vexing exceptions

Michael Hohlios — Mon, 15 Sep 2008 21:37:52 GMT

So this article sparked a bit of a controversy where I work.

We all agree with your logic of Vexing Exceptions but we do have one area that none of us can agree on.

When a user enters in the username and password does the login Manager throw and exception or does it offer a TryLogin?

Some of us believe it should be an Exception because you expect the user to be logged in and it is exceptional if the users credentials are incorrect.

While the rest of us think that you should always expect that the users input could be wrong making it not exceptional if they put in the wrong credentials.

So really the argument comes down to which persons point of view for an exceptional case is programmed for. Is it the user or is it the developer? Users expect to be logged in thus the Exception handling on login, however, the Developer expects the user to be incorrect thus no exception.

re: Vexing exceptions

Weeble — Tue, 16 Sep 2008 11:11:06 GMT

I don't see what's vexing with double.Parse other than that exception handling is so slow. Part of the value of exceptions is that you can't accidentally forget to check the return code and muddle on thinking that - in this case - the string was correctly parsed. So *is* this just about performance, or are there deeper reasons to dislike exceptions? What exactly is "vexing" about a method throwing an exception when it is unable to do what you asked of it? Many people seem to agree that "exceptions should only be thrown in exceptional circumstances", but everyone seems to understand something slightly different by "exceptional circumstances".

re: Vexing exceptions

Nick Meyer — Thu, 18 Sep 2008 20:20:16 GMT

@Michael

Interesting question: to add my $.02, I don't think the user's should care how this is implemented. All they need to know is that their credentials were incorrect, not how the login code treated the failure. Moreover, it's not necessarily exceptional to have the wrong credentials, particularly if you've changed your password recently, like I have ;)

I wouldn't say that the developer "expects" the user to be wrong, either. I think the developer doesn't know what to expect. Either case is as likely, so I would probably indicate the failure by a return value.

re: Vexing exceptions

Mormegil — Fri, 19 Sep 2008 15:25:52 GMT

I don’t like the concept of exogenous exceptions too much. There is nothing magical in exceptions in this situation – the OpenFile method (note that you did not use a constructor!) might as well return null (etc.) in case of an error instead of throwing an exception. The fact that you need to have atomic check/open has nothing to do with exceptions. So you could have categorized this as a vexing exception, too. The difference is just a bit of taste and syntactic sugar.

re: Vexing exceptions

chris — Mon, 22 Sep 2008 11:19:19 GMT

These are taught at university Java courses, in the format Inigo pointed out.

re: Vexing exceptions

Jarrod Ramsey — Mon, 22 Sep 2008 21:41:52 GMT

Good thoughts. I liked your definition of exceptions and your categories. Your pointing out the race condition was superb.

One thing I disagree with is not trying to catch them. I try to catch everything so I may log the errors. Otherwise, the error may thrown and the program die, but the admin won't know what caused it. Could bad logic have allowed the program to terminate willingly, even though it wasn't ready to end or did someone send a kill signal to it?

And even though they can be a pain, .NET stack traces have the ability to provide some critcal information, so if you do nothing more than catch and log a general exception, you have set your self up to proactively understand what caused your program to cease.

Secondly, you stated to not catch bonehead exceptions. In my opinion, you never want the exception to be thrown up the stack until it displays the trace to the screen or spit out an unhandled exception error for the user to see. Log it, email it, anything, but do something with it, then rethrow it or return a "polished" error message.

re: Vexing exceptions

David Nelson — Tue, 23 Sep 2008 18:04:59 GMT

@Jarrod

I think you took Eric too literally. When he says "don't catch" these exceptions, he means don't catch them at the point where they occur in an attempt to soldier on despite the problem. Of course it is good practice to use a global error handler to log any "unhandled" exceptions that reach the start of the call stack, and display an appropriate error message to the user.

re: Vexing exceptions

Eric Lippert — Tue, 23 Sep 2008 18:13:22 GMT

Sure. Use mechanisms (such as Watson) to backstop exceptions and report them to the user, or, even better, to the development team.

re: Vexing exceptions

madduck — Thu, 25 Sep 2008 11:25:35 GMT

The problem is trickier than it seems. If the blah blah blah code itself throws a FileNotFoundException, do you still want to catch it? Probably not, since it broadens the catch beyond its intent. You're quite prepared for the file at hand to be missing or unreadable, but do you really want the same catch block to trigger when a configuration file is missing deep inside some library code? More likely than not, you want the latter exception to go straight to the debugger. Delegates or lambdas provide an interesting generalised solution for this:

public static bool Exogenous<T, E>(Func<T> get, Action<T> use) where E : Exception

{

T value;

try {

value = get();

} catch (E) {

return false;

}

use(value);

return true;

}

Usage is quite simple, though some may need time to acclimatise:

if (!Exogenous<File, FileNotFoundException>(

() => OpenFile(filename, ForReading),

file => {

// blah blah blah

}))

{

// Handle filename not found

}

re: Vexing exceptions

Nick — Fri, 26 Sep 2008 13:49:27 GMT

Interesting article. One of the first things I do when I'm given unfamiliar code is search for "catch" to see what kind of developer(s) I'm dealing with.

Nothing bothers me more than two patterns (which I see far too often):

catch(Exception x)

{

throw Exception("Failed to achieve happieness");

}

and

catch(Excetpion)

{

// no code at all here

}

return false;

So while you're on the subject of catching things. Don't obliterate important debugging information in your catch block. Don't leave *any* catch block completely empty. If there's nothing to do then use

catch(Exception x)

{

// let the sap maintaining your code see what you're hiding.

if(Debugger.IsAttached)

Debug.WriteLine(x);

}

re: Vexing exceptions

Marc — Mon, 29 Sep 2008 17:32:12 GMT

I wish there were a way of checking a string is a valud guid, without calling new Guid(s) and catching the exception. I check it's length is 36, not exactly water proof.

re: Vexing exceptions

sam — Tue, 30 Sep 2008 13:29:46 GMT

Use a regex to match the string, no exception catching required.

Blog Carnival #6

IHateSpaghetti {code} — Wed, 01 Oct 2008 00:12:46 GMT

In this carnival there're a lot of software design/patterns and frameworks a bit of SOA, UML, DSL

re: Vexing exceptions

Michael — Wed, 01 Oct 2008 21:44:55 GMT

I really enjoyed this post and the attendant comments. I you ever felt inclined to address the related topic of when to throw exceptions, I would be a quite happy reader as you address the topic so well.

~Cheers~

re: Vexing exceptions

temp.stuff — Sat, 17 Jan 2009 21:44:14 GMT

I don't see the big difference between vexing and exogenous exceptions in the examples you made. Just like I could say that TryParse() can be implemented like this:

TryParse() {

try {

this.Parse();

} catch (...) {

return false;

}

I can say that a "TryOpen()" method can be implemented as:

TryOpen() {

try { this.Open(); }

catch(...) (return false;}

}

and with this new method there's no race when doing:

if (!FileExists(filename))

// Handle filename not found

else

using ( File f = TryOpenFile(filename, ForReading) )

{

// Blah blah blah

}