The Right Approach to Exceptions

[Jonathan M Davis]

On Sunday, February 19, 2012 10:10:36 Andrei Alexandrescu wrote:
> 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).

Transient may be a useful addition for some situations, but I don't think that 
it can replace a well-designed exception hierarchy. In general, what you want 
to do is handle exceptions differently based on what went wrong, not whether 
simply executing the same function call again might work on the second try.

Also, in many cases, you don't care about trying again. Your code is simply 
reacting differently depending on what went wrong, and it's not going to retry 
regardless.

- Jonathan M Davis