At 11:25 AM 8/4/00 +0200, Johan Vromans wrote:
>[Quoting Hildo Biersma, on August 4 2000, 08:40, in "Re: try/catch (Was: "]
> > Yes, but... this is largely casued by the fact that Java requires you to
> > declare any uncaught parameters on your method specification, and this
> > tends to have a nasty oil-slick effect.
> >
> > If you do it the C++ way, you can say:
> >
> > try {
> > first_sub_that_throws_exceptions();
> > second_sub_that_throws_exceptions();
> > } catch {
> > it went wrong
> > }
>
>How does 'it went wrong' know _which_ of the subs went wrong?
You use this model in the case where you don't care:
try {
sub_doing_database_stuff();
another_sub_doing_database_stuff();
# 32 more of the same
commit();
} catch {
rollback();
};
I am a big fan of http://search.cpan.org/doc/GBARR/Error-0.13/Error.pm.
You also want it for getting out of deeply nested calls to the first thing
that actually cares about it.
I don't want to give up the return-undef-for-error interface of builtins,
though; sorry if I gave that impression. Having both mechanisms a la
Fatal.pm looks attractive. Having structured exception objects so you
don't have to roll your own regexen parsing $@ is also very important...
oops, better save it for the new list...
--
Peter Scott
Pacific Systems Design Technologies
