At 08:11 PM 8/15/00 +0000, David L. Nicol wrote:
>What if "try" were implied by the appearance of "catch" keywords, which
>expire at the close of their block?
>
> catch [EXCEPTION [, ...] ] BLOCK
> ,...
> BLOCK
This is definitely a nifty concept that strikes me as very Perlish. At
least to begin with.
>the block would become:
>
>{ # prepare to call foo()
>
> catch Exception::MyDB, Exception::DBI {
> close_database();
> # other stuff
> }
> catch Exception::IO {
> close_network_connection();
> # other stuff
> }
> catch {
> my $err = shift;
> warn "Some other kind of error in foo: $err\n";
> throw $err; # Re-throw exception (just 'cuz we wanted to)
> }
> foo();
>};
>
>
>The reason is, this way, we don't have to keep track of, are we in
>a try or not, while running. We always are. An error happens, we
>back out of blocks until we find an appropriate catch if any. Retrying
>can be done with (failure coutners and) recursion or GOTOs.
>
>I believe that "try" occurs in C++ to mark the enclosed block as requiring
>special handling regarding stack unwinding. Since the perl stack is
>different than a C++ stack, we may not need to specify "try."
Right.
>Would someone please enlighten me as to the purpose of an explicit "try."
Well, for one, it makes it easier to see that a block is subject to
exception handling if all you have to do is look at the beginning for 'try'
rather than scan through it for a 'catch'. And there's the issue Jonathan
Scott Duff raised, which is that the question of which catch blocks will be
applied in what order is non-obvious to the user, even though there may be
a well-defined interpretation.
It's definitely something to think about, though.
--
Peter Scott
Pacific Systems Design Technologies
