The Right Approach to Exceptions

Andrei Alexandrescu SeeWebsiteForEmail at
Sun Feb 19 08:10:36 PST 2012

On 2/19/12 3:15 AM, H. S. Teoh wrote:
> I don't understand.  So instead of providing enough information to the
> caller about the nature of the problem, you're essentially handing them
> an anonymous note saying "A generic problem occurred, which _may_ go
> away if you retry. I have no further information for you. Do you want to
> retry?"?
> But without further information, how *can* you even make that decision?
> Without any way of determining what caused the error or even what it is,
> how could you know whether it makes sense to retry it?
> Or is that transient flag intended to mean that it *should* be retried
> since it "might" succeed the next time round? How should the caller
> decide whether or not to go ahead with the retry? Flip a coin? Always
> retry?  Always fail? I can't imagine any sane application where code
> would say "if this operation fails with a transient error, always fail"
> where any arbitrary set of exceptions might potentially be transient?
> What's a "transient error" anyway, from the application's POV anyway?
> What's a "transient error" from a database app's POV? A 3D shooter? A
> text editor? Is it even possible to have a consistent definition of
> "transient" that is meaningful across all applications?

I mentioned the definition a couple of times. Transient means retrying 
the operation with the same state may succeed. It is a property of the 
exception regardless of context. Of course, caller code may ignore it or 
use additional information.

Even network errors may be of both kinds. A network timeout error is 
transient. A DNS lookup error or malformed URL are not.

> It seems to me that if an error is "transient", then the called function
> might as well just always retry it in the first place, instead of
> throwing an exception.

Client code must decide on the appropriate action, including UI cues, a 
configurable number of retries, logging, and such.

> Such an exception is completely meaningless to
> the caller without further information. Yet it seems that you are
> suggesting that it's more meaningful than FileNotFoundException?

This is a misunderstanding. Transiency is a cross-cutting property. A 
FileNotFoundException is great (and non-transient btw).


More information about the Digitalmars-d mailing list