The Right Approach to Exceptions
gor.f.gyolchanyan at gmail.com
Mon Feb 20 06:26:31 PST 2012
Because the default behavior of the function regarding retries can be
What If you're willing to call the function for the first one which succeeds?
Implementing retry inside the function, which tries is a violation of
On Sun, Feb 19, 2012 at 10:54 AM, H. S. Teoh <hsteoh at quickfur.ath.cx> 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? Why
> doesn't the function concerned simply retry on its own? Network stack
> code does that. It would be nightmarish to program network applications
> if you always have to implement retry on your own (much less use
> *exceptions* to handle them)!
> Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry
More information about the Digitalmars-d