"Stephen P. Potter" wrote:
>
> I think fail() and handle() are good. Something fail()ed and
> it was handle()d by an exception.
Fail is no good, because exceptions can be used to indicate success.
Just because you don't isn't a counter-argument. Exceptions are
*not* the same as errors, that's just one semantic mapping.
Consider the following case. You've got some complicated algorithm
that doesn't normally succeed in finding an answer. When it does
find an answer, it can be all over the place, but no matter what,
you want to stop the algorithm and return the answer.
When you succeed, you want to say
throw Exception::MySuccess object => $answer_object;
not
fail Exception::MySuccess object => $answer_object;
and then invoke the whole algorithm under:
my $answer;
try { my_algorithm; }
catch Exception::MySuccess { $answer = $@->object; }
If my_algorithm finds the answer then $answer contains the answer,
otherwise $answer is undef. If my_algorithm throws anything but an
Exception::MySuccess (such as an otherwise uncaught internal Perl
error), the statement after the catch is not executed at all.
That's why all the other words with negative connotation are bad
choices for throw. It's up to the catcher to determine what's good
and what's bad, not the thrower.
The "classical" uses of try/throw/catch/finally have been around
for many years. During that time, many languages have incorported
the concepts, and after much heat and little light, the terminology.
Could it be that's because, *all* things considered, it is good
terminology?
Consider "finally" vs. "always". Always? Even if force majeur?
Finally simply means, "as the final act of the unwind processing".
By the way, this discussion has moved to perl-language-errors, so
the good folks here at perl-language-flow can concentrate on finding
silly words for other Perl flow-control constructs ;-)
Yours, &c, Tony Olekshy
