The Right Approach to Exceptions

Jonathan M Davis jmdavisProg at gmx.com
Sat Feb 18 23:12:20 PST 2012


On Sunday, February 19, 2012 00:43:58 Andrei Alexandrescu wrote:
> On 2/18/12 8:00 PM, H. S. Teoh wrote:
> >>  From this and other posts I'd say we need to design the base exception
> >> 
> >> classes better, for example by defining an overridable property
> >> isTransient that tells caller code whether retrying might help.
> > 
> > Just because an exception is transient doesn't mean it makes sense to
> > try again. For example, saveFileMenu() might read a filename from the
> > user, then save the data to a file. If the user types an invalid
> > filename, you will get an InvalidFilename exception. From an abstract
> > point of view, an invalid filename is not a transient problem: retrying
> > the invalid filename won't make the problem go away. But the application
> > in this case *wants* to repeat the operation by asking the user for a
> > *different* filename.
> > 
> > On the other hand, if the same exception happens in an app that's trying
> > to read a configuration file, then it *shouldn't* retry the operation.
> 
> I'm thinking an error is transient if retrying the operation with the
> same exact data may succeed. That's a definition that's simple, useful,
> and easy to operate with.

A core problem with the idea is that whether or not it makes sense to try 
again depends on what the caller is doing. In general, I think that it's best 
to give the caller as much useful information is possible so that _it_ can 
decide the best way to handle the exception.

- Jonathan M Davis


More information about the Digitalmars-d mailing list