The Right Approach to Exceptions

H. S. Teoh hsteoh at
Sun Feb 19 19:06:54 PST 2012

On Sun, Feb 19, 2012 at 08:34:30PM -0600, Andrei Alexandrescu wrote:
> On 2/19/12 7:58 PM, H. S. Teoh wrote:
> >On Sun, Feb 19, 2012 at 05:38:23PM -0600, Andrei Alexandrescu wrote:
> >>No dependence on context. The bit simply tells you "operation has
> >>failed, but due to a transitory matter". That is information local
> >>to the thrower.
> >[...]
> >
> >But *which* transitory matter? A temporary outage on the network? A
> >timeout due to excessive CPU load? A full disk (which is transitory
> >because some other process might remove a large file in the interim)?
> Doesn't matter.
> >Without knowing the context, this information is of little use.
> It is. User code may decide to retry the high-level operation (of
> which the low-level failure has no knowledge).

But on what basis will it make this decision? All it knows is that
something went wrong somewhere deep in the call stack, and it's
presented with a binary choice: retry or abort. It doesn't know what
that problem was. So how would it know if retrying would help? Saying
that it "might" help doesn't seem useful to me.

It's only useful if you present this choice to the *user* along with the
error message encapsulated in the exception, and let the user make the
decision on the basis of the error message.

I think we're all agreed that parsing the error message is not a viable
solution, so basically the catch block is presented with a blind binary
choice of which it knows nothing about.  Such a choice is meaningless to
a computer program.

Do you have a concrete scenario in mind where such a decision would
actually be useful? Otherwise we'll just end up with boilerplate code
copy-n-pasted everywhere of the form:

	auto retries = SomeArbitraryNumber;
	do {
		try {
		} catch(Exception e) {
			if (e.is_transient && retries-- > 0)
			throw e;
	} while(false);

But since this block is completely independent of what's inside the try
block, why not just put it where the exception is generated in the first


If the comments and the code disagree, it's likely that *both* are
wrong. -- Christopher

More information about the Digitalmars-d mailing list