On Tue, 22 Aug 2000, Glenn Linderman wrote:
> I'm suddenly intuiting that maybe you want to continue execution after the sub
> call that caused the throw. But if you continue, you won't have the return
> values from the sub call. Where should the continuation take place for
> something like:
>
> l1:
> $a = & foo ( & bar ( $b ));
> l2:
> & baz ( $a );
> l3:
>
> in the two different cases that &bar throws, and that &foo throws? If you
> continue "immediately after" the sub call, and &bar throws, &foo is likely to
> get bad parameters and also fail. And if you say the next statement after a
Yes, that's true, but I'm not talking about such cases. Your above
example would result in garbage in, garbage out which is ok if I want to
circumvent the exception system. Maybe it's easier to understand if I
explain what I do not want to have ;-)
I'd normally use such a pragma when I want to write a small hack, not a
large project. What I fear are that certain modules will die on me even on
stuff comparable to e.g. unlink in side effects - as they simply want to
throw an exception as a means of reporting "file is not there anyway" -
which I absolutely do not care about...
E.g. in Java writing small hacks is impossible because you'll spend half
your time adding try/catch blocks around stuff... Perl is a bit better in
that respect - it allows me the choice to forget completely about
exceptions or having the same trouble as in Java....
What I request is probably similar to the no Fatal pragma someone
proposed. The only thing I dislike about no fatal is that modules are
supposed (are they really?) to return error return values then - and what
I'd like to have is still that I CAN catch exceptions at some points, but
I need not to. If I don't check it, I'll simply get an undef return
value, but I still have the choice to check one or two possible
exceptions without enabling/disabling all that myself.
The current definition of use fatal/no fatal would not allow this I think
as suddenly those modules could stop throwing exceptions, so I'd end up
enable/disabling use fatal all the time...
Another way to achieve the same result would be to NOT get rid of the try
part of try/catch and then try automatically implies use fatal for that
block...
--
Markus Peter
[EMAIL PROTECTED]
