Markus Peter wrote:
> 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 ;-)
Well, explaining what you want to have is one view of a thing, and explaining what
you do not want to have is another view of a thing, and if they are the same thing,
then sometimes one explanation can be clearer than the other. So we read on...
> 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...
Well, if they die on you, there's not much you can do about it. But if they throw
an exception, you will only die if you don't catch it.
> 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....
Perl 5 doesn't have exceptions, which is precisely how it avoids this problem.
Instead, you trade that for checking return codes ... when you care.
> 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.
But this sounds different that your "want" proposal, because there you said you
wanted all exception that propagated to main to be ignored, and now you say only
some of them. Perchance you didn't want what you said you did? Or that you are
changing your mind.
> 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...
Yes, I rather think you would.
> 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...
This is the first functional use for a try keyword/block that I've heard!
But the same effect can be achieved with or without the keyword.
Effectively, you want to partition your program into sequentially executed
fragments, alternating between having exceptions be ignored, and having exceptions
be handled. Let's reduce this two exactly two fragments, the first of which has
exceptions ignored, and the second of which has exceptions handled. To be
interesting, the first fragment needs to have multiple statements, either of which
could have an internal throw... let's call them S1; and S2; The second fragment
will consist of statements S3; and S4;
So with RFC 88 syntax (with a try block) you could:
try { S1; } catch {}; # individual try/catch wrappers
try { S2; } catch {}; # to ensure execution of next statement
try { S3; S4; } catch { handler_code; };
With RFC 119 syntax (no try block) you could:
S1; catch {}; # individual catch handlers
S2; catch {}; # to ensure execution of next statement
S3; S4; catch { handler_code };
Or with a pragma
{ use no uncaught_throws_fail;
S1; S2;
}
S3; S4; catch { handler_code };
Now if there are many statements in fragment one for which you do not want uncaught
throws to fail, the pragma could be a more consise expression of your goal. But if
the statements for which you do not want uncaught throws to fail are intermixed with
statements for which you want to handle exceptions, then either syntax is somewhat
verbose.
> --
> Markus Peter
> [EMAIL PROTECTED]
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_______________________________________________
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
