The Right Approach to Exceptions

deadalnix deadalnix at gmail.com
Sun Feb 19 04:35:02 PST 2012


Le 19/02/2012 09:02, Andrei Alexandrescu a écrit :
> On 2/19/12 12:54 AM, H. S. Teoh wrote:
>> On Sun, Feb 19, 2012 at 12:43:58AM -0600, 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.
>> [...]
>>
>> But if that's the case, what's the use of an exception at all?
>
> Centralization.
>
> Andrei
>

Please stop answering like that. From the begining of this topic 
Jonathan M Davis, H. S. Teah (and myself ?) raised very valid points. 
What do you expect from that discussion if yourself you do not put any 
arguement on the table ?


More information about the Digitalmars-d mailing list