TITLE: exceptions and recovery information ME: Mike Evans (mevans@rdatasys.com) KH: kjhopps@mmm.com (Kevin J Hopps), 30 Nov 95 ME: I've seen a lot on this thread. It seems that most people are concerned with logging the exception and how to debug them. What about the not-so-freqently mentioned cases where an exception is something that you can handle? How about including some type of information in the exception that will allow you to deal with the error...maybe put up a nice error message, and keep going as if the world hasn't ended? KH: Logging exceptions is sometimes important, but hopefully they will be recovered regardless of whether they are logged. The exception should (IMHO) contain information sufficient for recovery. This means that when designing and throwing exceptions, one must be cognizant of the needs of the handler. ME: While you can catch a specific type of exception class in your catch statement, I certainly don't want to make a new class type for each specific type of error I might have. While there are general classes of errors (such as allocation), there might be any of several errors that are "unexpected states" or something like that...and the world shouldn't end because of them. KH: There are tradeoffs to be made between having separate classes to distinguish different errors and having smaller numbers of classes with data to distinguish different errors. Having separate classes allows you to write catch statements only for errors you can actually handle. Without separate classes, you must catch if you might be able to handle the error, and rethrow if you can't. ME: I've been thinking a lot lately about the best way to deal with such things. In some situations, I can even fix the problem. Parsing a why() string isn't exactly what I want to do to figure out what I need to do to handle the problem. I'm considering some kind of class like "InternalException" that stores, in addition to the "why" information, some type of error ID. I can then use this information to see if the returned error ID is something I know how to handle at that location....maybe the user deleted a data file I'm looking for and I can write a default one...or a record is missing from my data that I didn't expect. KH: One should not (IMHO) ever have to parse a why() string to figure something out. The why() string should (IMHO) be for people to read, not for programs to read. If there is information needed by the handler for recovery, that information should be provided in a form that is convenient to the handler. ME: I know there's been disagreements as to what even should be an exception... everywhere from only using them in "near death" experiences to using them for any routine error handling. I'm certainly not restricting myself to the "near death" classification. I find them useful in cleaning up code...you don't have to check every return value...you can expect that things worked or you'll know about it in your handler, and can deal with it. That's why I'm thinking that there ought to be more practical information than a line number and an exception trace. I want to include information that will help me solve the problem, and not have tons of derived exception classes. KH: I find the line number and source file very convenient during debugging. But that information is never used to perform recovery. Other information (such as the unix errno value) is used to make decisions.