On Tue, 22 Aug 2000, Glenn Linderman wrote:
> > 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.
With "die on me" I meant not usage of "die" but throwing exceptions I do
not care about catching...
> > 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.
I talk about the current proposals for Perl 6
>
> > 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.
I know exactly what I want. Wether I currently lack the ability to express
myself is another question ;-)
I spoke about propagation to the top-most level - which is the interpreter
- which is another way of speaking about uncaught exceptions in most
languages.
> > 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.
>
> ....
>
> Or with a pragma
>
> { use no uncaught_throws_fail;
> S1; S2;
> }
> S3; S4; catch { handler_code };
This is basically what I talk about, just that I'd prefer the try notation
to the use one. I usually like seeing the begin of a catch block marked
explicitely. Many many exception handlers end up doing only mimimal
handling (like error output and then continueing or simply returning to
the main program) so they usually end up being one-liners - which is not
possible with use or whatever... All statements to switch exception
handling off/on longer than 3 characters are a waste...
Hmm... guess I could have had this explained a lot faster - what I
actually want is: I want to handle exceptions only if I'm in the mood to.
Example (for those who could still not see any sense in my words ;-):
use no fatal;
bla;
....
bla;
# should any of the above code throw an exception it gets ignored
try {
# from this point on i handle exceptions - use fatal is implied
foo;
} catch ...; # handle exception
bar;
...
bar;
# exceptions automatically ignored again
--
Markus Peter
[EMAIL PROTECTED]
