I don't think anyone is interested in a debate on this subject; but, I'll respond to a couple of your questions:
>Second, I would like to say that there are some cases where you might >want to catch Exception when trying to open a file. It's pretty much >guaranteed that if an Exception of any type is thrown while you're >trying to open a file, then the file couldn't be opened. Why would you make that assumption? File.Open() lists exceptions that it might throw in that version of the assembly; but, those aren't the only exceptions that can be caught by calling File.Open()--one of the many methods that File.Open() may call might throw many different other exceptions that File.Open() doesn't handle. How can you be sure that you can handle ALL of those exceptions and that one of the methods on the stack that led to the calling of your method isn't going to handle a particular exception with much better context than you? Not to mention new exceptions added to new versions of the assembly where File.Open resides. Sure, a method that calls File.Open is probably in a prime context (or should be) to handle FileNotFoundException, DirectoryNotFoundException, a subset of IOException exceptions, or NotSupportedException; but handling exceptions like UnauthorizedAccessException might better be handled further back in the stack where authorization context is known. (I'd argue, in the case of File.Open(), that ArgumentException, ArgumentNullException, and ArgumentOutOfRange are fatal and you might as well let them bubble back down the stack as some data validation routine has failed and the application invariants have been trashed.) >Also, is there something wrong with catching Exception and then showing >a message based on its type, with some sort of an "Unknown Error" >message being shown if it's a totally unexpected Exception? Maybe the >task of choosing a message for the Exception can be performed by some >function. Again, if something back in the stack is also handling that exception (of which, your function cannot know) you're duplicating functionality and probably presenting repetitive messages if you simply rethrow after presenting a message. If heard the argument regarding "I know all the code"; but, you're still coupling the method calling File.Open() to any method that could be in the stack when File.Open() is called and that they *WON'T* try to catch any exceptions that the method doesn't really handle. Anyway, I've reiterated about as much as I need to about the subject on this list. If you want to continue a debate, send me a private message. http://www.peterRitchie.com/ =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
