The Right Approach to Exceptions

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sun Feb 19 00:06:38 PST 2012


On 2/19/12 1:12 AM, Jonathan M Davis wrote:
> 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.

That sounds like "I violently agree".

Andrei



More information about the Digitalmars-d mailing list