One of the things I don't like about traditional try/catch handling is
that it doesn't allow for class level programming. You need to allow
any subroutine to try/catch exceptions (die). It's also nice to
notify any object in the stack that there is an unhandled exception
passing through
I'm afraid I don't get it - isn't it what the finally functionality
in Error.pm (CPAN) does ?
try {
stuffThatMayThrow();
} finally {
releaseResources();
};
One reason for exceptions is to separate error handling code from the
normal control flow. This makes the normal
On Mon, 14 Jan 2002, Rob Nagler wrote:
I'm afraid I don't get it - isn't it what the finally functionality
in Error.pm (CPAN) does ?
try {
stuffThatMayThrow();
} finally {
releaseResources();
};
One reason for exceptions is to separate error handling code from
On Fri, 11 Jan 2002 17:39:33 -0500
Jay Lawrence [EMAIL PROTECTED] wrote:
For what it is worth - I would encourage you to check out the Error package
as well.
Exactly,
in fact the module can nicely work with Error.pm. See t/*.t for
details ;)
--
Tatsuhiko Miyagawa Livin' On The
On Fri, 11 Jan 2002 17:34:30 -0600 (CST)
Dave Rolsky [EMAIL PROTECTED] wrote:
You would have:
try {
code;
} catch FooException with {
code for FooExceptions;
} catch BarException with {
code for BarExceptions;
} otherwise {
};
And
On Sat, 12 Jan 2002, Tatsuhiko Miyagawa wrote:
On Fri, 11 Jan 2002 17:34:30 -0600 (CST)
Dave Rolsky [EMAIL PROTECTED] wrote:
You would have:
try {
code;
} catch FooException with {
code for FooExceptions;
} catch BarException with {
On Sat, 12 Jan 2002 10:25:23 + (GMT)
Matt Sergeant [EMAIL PROTECTED] wrote:
Matt has an idea for doing this with Filter module, instead of
nasty closures.
Actually unfortunately I even had code, but it was on my laptop that died.
Sad.
I may resurrect the project in time for this
Matt Sergeant writes:
I don't like this for the same reason I don't like $SIG{__DIE__} - it
promotes action at a distance. In a 1000 line .pm file I *want* to have my
exception catching mechanism next to my eval{} block.
You need this flexibility, but Perl allows you to do more, for good
Seeing through Dave Rolsky's Exception::Class and
Sig::PackageScoped has let me make the following module, called
Exception::Handler.
In fact I rarely use $SIG{__DIE__} for exception handling, but the
concept of the module would be a bit interesting. Especially
eval { };
if ($@-isa
]; Matt Sergeant [EMAIL PROTECTED]
Sent: Friday, January 11, 2002 8:07 AM
Subject: RFC: Exception::Handler
Seeing through Dave Rolsky's Exception::Class and
Sig::PackageScoped has let me make the following module, called
Exception::Handler.
In fact I rarely use $SIG{__DIE__} for exception
On Fri, 11 Jan 2002, Jay Lawrence wrote:
For what it is worth - I would encourage you to check out the Error package
as well.
Rather than:
eval { };
if ($@-isa('FooException')) {
# ...
} elsif ($@-isa('BarException')) {
# ...
} else {
# ...
}
You would
On Fri, 11 Jan 2002, Tatsuhiko Miyagawa wrote:
use Exception::Handler
MyException = \my_handler,
AnotherException = \another_handler,
__DEFAULT__ = \default_handler;
eval { MyException-throw }; # my_handler()
eval { AnotherException
I am trying to get the exception class described in the guide to work, but am having
trouble with die returning the class incorrectly.
The example in the guide was:
die My::Exception-RetCode(code = 204);
The module code is at:
13 matches
Mail list logo
