2000-08-22-15:13:23 Peter Scott:
> I too would rather say
>
> my $fh = open $filename or die "Couldn't copy source: $!"
>
> than
>
> my $fh; try { $fh = open $filename } catch { die "Couldn't copy
> source: ", $@->syserr }
I'd usually rather just say
my $fh = open $filename;
and be done with it, but then I'd always "use Fatal qw(:all);". But
if I'd done such a "use Fatal", and then wanted to catch one, I sure
hope I wouldn't have such a rabid try/catch bru-ha-ha inflicted on
me; couldn't I just say
my $fh = eval { open $filename } or whatever ...;
die/eval works really sweetly; I haven't figured out why people
want to replace eval { BLOCK } with try/catch. If you want more
structured data in the exception, make $! an arbitrary complex
object that stringifies to the text message.
> Module authors should also be able to take advantage of Fatal.pm.
> "use Fatal" should set something that can be checked by any
> programmer (heck, that doesn't even have to be restricted to
> module authors; the creator of an insanely large program might do
> it). The programmer can use this to decide whether to throw an
> exception or return. [Bennett, this impacts RFC 70 in IMHO a good
> way; you may consider expanding its scope to be not just binding
> on the core, but advisory for everything else. Perhaps suggest an
> interface whereby user code can see what the setting is.]
I beat you to it. While RFC 70 was intended to just request that it
be possible to finish Fatal.pm so it works as intended and desired,
it does mention:
If [the finishing-up of Fatal.pm, after fixing the busted core]
were a success, then the requested category could also be posted
into a testable variable, allowing module authors who wished to
to automatically support this functionality as well.
:-)
-Bennett
PGP signature
