Glenn Linderman wrote:
>
> Some discussion has been made about ignoring errors from certain
> parts of the code. This is the only item that gets more complex
> with exception handling--they must be ignored explicitly
>
> { & ignore_my_errors ( @params ); catch {}};
I don't see how it gets more complicated if you really want to
ignore errors. If you really want to ignore errors, you have to do
this in Perl 5 right now anyway, but you say eval { ... }; instead.
What people really want is to ignore failure returns only, and
still get the benefit of Perl's or the module author's judgement
call on when to die because it's "really" serious. So do I,
sometimes, when I'm at that level of DWIM. That's why RFC 88
doesn't affect that current Perl 5 behaviour.
> "enabling/disabling fatality for exceptions with a pragma"... if
> the idea is that control continues linearly past a throw, then
> sub/module authors must write twice the error handling logic,
Exceptions should not be disableable except under the conditions
discussed in RFC 88. Internal to their modules, authors can use
scoped C<use fatal;> if they want exception-based from the ground up.
Then, and only if they want to support the other style, and only for
public API subroutines, they do something like one of these:
- Use return internal, now add support for throw at API:
sub Foo
{
my $err_code = ... ; # real code goes here
# Replace the old return $err_code with this:
return $err_code unless $FATAL_MODE && $error_code != $ok;
throw Error::Code "Couldn't Foo.", code => $err_code;
}
- Use throw internal, add support for return at API:
sub Foo
{
try {
# real code goes here, may execute:
throw Exception "Couldn't foo.", code => $err_code;
}
catch !$FATAL_MODE => { return $@->{code}; }
return $ok;
}
Remember, this is only for the public API subroutines, all the
internal routines use one style or the other and are unaffected.
That's not too hard, for someone who wants to make such a robust
module in the first place. And if they don't, they don't have
to use throws or trys at all.
If I want exception-based code, and a module doesn't do it, I'll
just keep doing the same thing I do now (if I'm writing code that
needs to be robust):
try { my $err_code = Module::Foo(); }
finally { $err_code == $ok or
throw Exception "Can't Module::Foo.", code => $err_code }
this is, of course, just a slightly fancier version of
open ... or die ...;
Yours, &c, Tony Olekshy
