On 2/19/12 9:06 PM, H. S. Teoh wrote:
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.
No. The information is: "There's been failure, but due to a transitory
cause." In a high-level transaction, it doesn't matter which particular
step failed. If whatever failure was transitory, the transaction can be
attempted again.
It doesn't know what
that problem was.
Doesn't have to.
So how would it know if retrying would help? Saying
that it "might" help doesn't seem useful to me.
Retrying helps because the error happened because of a temporary cause.
That info is known at the raise place, and nicely passed up to the
high-level command.
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.
That's up to the application. A server application, for example, can't
ask the user. We log and we have configurable number of retries.
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)
continue;
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
place?
I explained this. The raise locus does not have access to the high-level
context.
Andrei
