> On Sun, 4 Apr 2004 22:53:36 +1000, John Elliot <[EMAIL PROTECTED]> wrote:> >difficult to handle. I design my code such that exceptions don't happen. >If they do, then I have a bug and I need to fix it, I don't pretend that >I can really 'handle' an exception (obviously there are cases where you >have to, but I try to avoid these), despite its politically correct name >I still consider it an 'error' and I generally terminate my process. To >try and handle all the possible states that you could be in when you >receive an exception seems almost impossible to me. >
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. I mentioned this before in another dotnet list, but if your app crashes because it can't write a file MRU list out to a roaming profile (say there are network problems) that's very bad IMO. In this scenario the error isn't a big deal at all. Just notify the user of the problem (or not) and move on. However, in order to do this you have to catch and handle the appropriate exception at the point you try to open the file you keep the MRU list in. With the WIN32 API this sort of problem would probably have just been ignored and even if it wasn't, the error wouldn't have propagated to some unhandled exception handler. A simple "if" statement would have spotted the problem and the app would have dealt with it appropriately. Unfortunately, with the positive aspects of "you can't ignore exceptions" comes the following somewhat negative aspect. The application *developer* is responsible checking for every possible recoverable exception and handling those in the appropriate manner. Otherwise, your app will crash (probably often) and your users will become annoyed with you. 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. 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. In the end, I think the best thing Microsoft could do is provide a compromise solution to the lack of checked exceptions in .NET. The compromise is to at least provide compiler support for determining all exceptions thrown by each type member and provide this info in Intellisense and also in the docs. I imagine for compilers that haven't been updated to support this feature you would have to provide some static anaylsis tool for assemblies generated by those older gen compilers. Perhaps this same analysis tool could tell you about all the exceptions that you are letting escape from each type member. Yikes! I bet that would be one scary long report! Seriously though, relying on developers and doc writers to get the list of thrown exceptions correct is a disaster in the making. -- Keith =================================== 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
