Front page | perl.perl6.language.errors |
Postings from August 2000
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 warp@spin.deThread Previous | Thread Next