>I think perhaps we (developers) have become far too forgiving of apps >that crash. :-) Frankly I am very annoyed when an app that I've paid >good money for crashes and takes my data with it or causes me to lose >time. For this reason, it seems to me that applications should try very >hard to recover from exceptions if at all possible. If not, at least >give the user a chance to save their data (and to an alternate >file/store in case the data is corrupted). As it turns out with .NET >apps, a *lot* of exceptions are recoverable.
Trying to recover from exceptions is extremely difficult. It's far better to try very hard to avoid them. >Seriously, I have been using Quicken for years (since 1990) and I can't >remember the last time it crashed on me. It has to have been at least >6-8 years. For me, an 'exception' is something that my code hasn't catered for, by definition it really can't be handled. I reckon Quicken (or other reliable software) is simply well coded, it has a code path for all situations and manages to maintain valid state. Again, it's far easier to do this by avoiding things that can cause exceptions, than handling them. You need good boundaries when you handle exceptions so that you know state you subsequently rely on has not been corrupted. >Why shouldn't end users of .NET apps be able to get that >same level of reliability (rhetorical question)? One reason is that the >exceptions thrown by the FCL and 3rd party libraries aren't always >correctly documented. I can't remember the specific case but there was >one exception we ran into on an app and it was *not* documented in the >FCL docs to throw that exception! What the heck is a developer supposed >to do in this case? Test, test and test some more is about it. Handling exceptions isn't really the way to go. It's easy to get stuck in the mindset that you should try and catch every external call and make some attempt at recovery, but it's just impossible. Exception handling should be rare IMO, basically a root handler, and handlers for IO exceptions. Trying to handle an ArgumentException or a NullReferenceExcetpion is madness. You might like to handle a FileNotFoundException in the off chance that it gets deleted in the few nanoseconds after your code that checks it exists runs so that you can handle this extremely rare and unlikely to happen again (or at all) case, but you shouldn't really have to handle a FileNotFoundException because the file isn't there (you should check if it's there). Some exceptions like StackOverflow or OutOfMemory can't really be handled, and could happen anywhere, attempts to recover would likely fail anyway. They are the result of a serious bug, and you can't pretend that you can continue to execute, basically your software doesn't work. >Seriously though, relying on developers and doc writers to get the list >of thrown exceptions correct is a disaster in the making. I would very rarely trust a 3rd party API which threw me an exception to still be holding valid state, particularly if they rely on global (static) state. Exceptions are a hard problem, the way I look at it is I do everything I can to avoid them, I test the crap out of my software, and that's it. Yes I handle them, but only when I absolutely must, and only at a point where I can still assert that my state is valid. More often I see bugs introduced from an attempt to handle exceptions than I do from an attempt to avoid them. At least in the latter case you find out about errors in your code, rather than having subtly corrupted state around. John. =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
