Re: RFC: Exception::Handler
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 its code.
I'm afraid I don't get it - isn't it what the finally functionality
in Error.pm (CPAN) does ?
try {
stuffThatMayThrow();
} finally {
releaseResources();
};
This eliminates a lot of explicit
try/catches.
Well, destructors are of some help too in that issue.
(not lighting up a flamewar, just trying to understand the issues - I
don't know much about Aspects, but I find exception handling with
Error.pm a breeze, even for big projects)
--
Tout n'y est pas parfait, mais on y honore certainement les jardiniers
Dominique Quatravaux [EMAIL PROTECTED]
Re: RFC: Exception::Handler
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 control flow easier to
read. If releaseResources() is to be called whenever an exception
occurs, then it is advantageous to eliminate the extra syntax in the
class's methods and just have releaseResources() called whenever an
exception occurs and the object is on the stack.
Our exception handling class searches down the stack looking for
objects which implement handle_die(). It then calls
$object-handle_die($die), where $die is the exception instance. This
increases the cost and complexity of exception handling, while
decreasing the cost and complexity of normal control flow. It also
ensures that whenever the object is involved in an exception,
handle_die() is called giving it an opportunity to examine the
exception and clean up global state if necessary.
This eliminates a lot of explicit
try/catches.
Well, destructors are of some help too in that issue.
Not if the object is a class or if the object is still live, e.g. the
request context. We don't do a lot of instance creation/destruction
in our code. For example, our Task instances are created at start up.
They are executed repeatedly. Tasks decide whether to commit/rollback
on every execution, independent of the path through the Task class.
I'm agree with the need for try/catch. That's often the best way to
handle exceptions. There are cases where a global view is need,
however. Like Aspects, it ensures that you don't forget or have to
put in code where it is absolutely needed.
Rob
Re: RFC: Exception::Handler
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 the
normal control flow. This makes the normal control flow easier to
read. If releaseResources() is to be called whenever an exception
occurs, then it is advantageous to eliminate the extra syntax in the
class's methods and just have releaseResources() called whenever an
exception occurs and the object is on the stack.
Our exception handling class searches down the stack looking for
objects which implement handle_die(). It then calls
$object-handle_die($die), where $die is the exception instance. This
increases the cost and complexity of exception handling, while
decreasing the cost and complexity of normal control flow. It also
ensures that whenever the object is involved in an exception,
handle_die() is called giving it an opportunity to examine the
exception and clean up global state if necessary.
Might be a fun thing to try out using the mysterious PROPOGATE method (try
it - implement a PROPOGATE method in your exception class, and watch for
when it gets called).
--
!-- Matt --
:-Get a smart net/:-
Re: Exception::Handler
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 EDGE, Co.,Ltd. mailto:[EMAIL PROTECTED] http://www.edge.co.jp/
Re: Exception::Handler
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 the fun potential for memory leaks with nested closures.
Matt has an idea for doing this with Filter module, instead of
nasty closures.
AFAICT, Tatsuhiko's module is designed to work with either of those types
of objects transparently, but it provides an alternate mechanism for
catching exceptions.
Absolutely.
And anything inspired by my Sig::PackageScoped module scares me,
Yep. the module is greaty inspired, and in fact borrows its some
code from Sig::PackageScoped!
but its an interesting idea ;)
--
Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: Exception::Handler
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 {
code for BarExceptions;
} otherwise {
};
And the fun potential for memory leaks with nested closures.
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.
I may resurrect the project in time for this year's Perl Conference,
provided Tony Blair decides to instigate my vision of a 30 hour day.
--
!-- Matt --
:-Get a smart net/:-
Re: Exception::Handler
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 year's Perl Conference, provided Tony Blair decides to instigate my vision of a 30 hour day. AFAIK Filter module can't work with eval EXPR code, thus making Apache::Registry unhappy. -- Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: RFC: Exception::Handler
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
reasons.
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 its code. This eliminates a lot of explicit
try/catches. This allows reuse without clutter. If you're familiar
with Aspects, it's basically the same concept.
Rob
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 handling, but the
concept of the module would be a bit interesting. Especially
eval { };
if ($@-isa('FooException')) {
# ...
} elsif ($@-isa('BarException')) {
# ...
} else {
# ...
}
code like this can be greatly simplified.
Any suggestions welcome, escpecially from gurus of exception, Matt
and Dave ;) See t/*.t for typical usage.
http://bulknews.net/lib/archives/Exception-Handler-0.01.tar.gz
NAME
Exception::Handler - Hierarchical exception handling
SYNOPSIS
use Exception::Class
'MyException',
'AnotherException' = { isa = 'MyException' },
'YetAnotherException' = { isa = 'AnotherException' },
'FooBarException';
use Exception::Handler
MyException = \my_handler,
AnotherException = \another_handler,
__DEFAULT__ = \default_handler;
eval { MyException-throw }; # my_handler()
eval { AnotherException-throw; };# another_handler()
eval { YetAnotherException-throw; }; # another_handler() : hierarchical
eval { FooBarException-throw; }; # default_handler()
sub my_handler {
my $exception = shift;
# ...
}
sub another_handler { }
sub default_handler { }
DESCRIPTION
Exception::Handler allows you to handle exception with various subs each
of which registered for an appropriate class of exception. This module
can nicely work with Dave Rolsky's Exception::Class and Grahamm Barr's
Error module.
TODO
* Lexical handler, which may be done via local.
AUTHOR
Tatsuhiko Miyagawa [EMAIL PROTECTED]
This library is free software; you can redistribute it and/or modify
it under the same terms as Perl itself.
SEE ALSO
Exception::Class, Sig::PackageScoped
--
Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: Exception::Handler
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 have:
try {
code;
} catch FooException with {
code for FooExceptions;
} catch BarException with {
code for BarExceptions;
} otherwise {
};
And you can throw exceptions with details on the nature of the exception:
throw FooException ( -text = You foo'ed at line bar, -value =
$line );
and in the try block:
try {
do foo;
} catch FooException with {
my $exception=shift;
print Uh oh, we have a problem with foo: . $exception-text;
};
Jay
- Original Message -
From: Tatsuhiko Miyagawa [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Dave Rolsky [EMAIL PROTECTED]; 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 handling, but the
concept of the module would be a bit interesting. Especially
eval { };
if ($@-isa('FooException')) {
# ...
} elsif ($@-isa('BarException')) {
# ...
} else {
# ...
}
code like this can be greatly simplified.
Any suggestions welcome, escpecially from gurus of exception, Matt
and Dave ;) See t/*.t for typical usage.
http://bulknews.net/lib/archives/Exception-Handler-0.01.tar.gz
NAME
Exception::Handler - Hierarchical exception handling
SYNOPSIS
use Exception::Class
'MyException',
'AnotherException' = { isa = 'MyException' },
'YetAnotherException' = { isa = 'AnotherException' },
'FooBarException';
use Exception::Handler
MyException = \my_handler,
AnotherException = \another_handler,
__DEFAULT__ = \default_handler;
eval { MyException-throw }; # my_handler()
eval { AnotherException-throw; };# another_handler()
eval { YetAnotherException-throw; }; # another_handler() :
hierarchical
eval { FooBarException-throw; }; # default_handler()
sub my_handler {
my $exception = shift;
# ...
}
sub another_handler { }
sub default_handler { }
DESCRIPTION
Exception::Handler allows you to handle exception with various subs
each
of which registered for an appropriate class of exception. This module
can nicely work with Dave Rolsky's Exception::Class and Grahamm Barr's
Error module.
TODO
* Lexical handler, which may be done via local.
AUTHOR
Tatsuhiko Miyagawa [EMAIL PROTECTED]
This library is free software; you can redistribute it and/or
modify
it under the same terms as Perl itself.
SEE ALSO
Exception::Class, Sig::PackageScoped
--
Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: Exception::Handler
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 have:
try {
code;
} catch FooException with {
code for FooExceptions;
} catch BarException with {
code for BarExceptions;
} otherwise {
};
And the fun potential for memory leaks with nested closures.
And you can throw exceptions with details on the nature of the exception:
throw FooException ( -text = You foo'ed at line bar, -value =
$line );
You can do that without using Error.pm's try/catch stuff by simply using
Error's exception objects or the Exception::Class provided exception
objects.
AFAICT, Tatsuhiko's module is designed to work with either of those types
of objects transparently, but it provides an alternate mechanism for
catching exceptions.
And anything inspired by my Sig::PackageScoped module scares me, but its
an interesting idea ;)
-dave
/*==
www.urth.org
we await the New Sun
==*/
Re: RFC: Exception::Handler
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-throw; };# another_handler()
eval { YetAnotherException-throw; }; # another_handler() : hierarchical
eval { FooBarException-throw; }; # default_handler()
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.
--
!-- Matt --
:-Get a smart net/:-
Problem with exception handler in guide?
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:
http://thingy.kcilink.com/modperlguide/perl/The_My_Exception_class_in_its_e.html
with two modifications (the last die in sub AUTOLOAD was changed to CORE::die to
prevent a perl warning message about it being ambiguous, and the missing semicolon at
the end of the first line package ... was added).
The following script code does not work
#-
use My::Exception;
eval {
die My::Exception-Return(code = abc);
};
if ($@) {
use Data::Dumper;
print Dumper($@);
}
#-
It generates the output:
#-
$VAR1 = bless( {
'text' = 'My::Exception',
'caller' = {
'line' = 19,
'filename' = 'My/Exception.pm',
'package' = 'My::Exception'
}
}, 'My::Exception::UnCaught' );
#-
with the class indicating that the exception was not caught. Tracing it in the
debugger shows that it executes My::Exception::die using My::Exception as the first
argument.
If I put parens around the argument to die, as follows, it works (calls AUTOLOAD first
then returns result of that as first argument to My::Exception::die), returning the
correctly classed object.
Code:
#-
use My::Exception;
eval {
die (My::Exception-Return(code = abc));
};
if ($@) {
use Data::Dumper;
print Dumper($@);
}
#-
Output:
#-
$VAR1 = bless( {
'caller' = {
'line' = 5,
'filename' = './exceptions2',
'package' = 'main'
},
'code' = 'abc'
}, 'My::Exception::Return' );
#-
It appears that - is too low a precedence. Is there a way around this without
requiring that parentheses be used around die's arguments? I'm running this under
perl5.6.0. Here is output of perl -V:
Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.0, archname=i586-linux
uname='linux manson 2.4.0 #1 wed aug 2 20:22:26 gmt 2000 i686 unknown '
config_args='-ds -e -Dprefix=/usr -Di_db -Di_dbm -Di_ndbm -Di_gdbm'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define
use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
Compiler:
cc='cc', optimize='-O2 -pipe', gccversion=2.95.2 19991024 (release)
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64'
stdchar='char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -ldl -lm -lc -lcrypt
libc=, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under linux
Compiled at Jan 19 2001 05:42:10
%ENV:
PERL5LIB=/home/mpressly/development/library
@INC:
/home/mpressly/development/library
/usr/lib/perl5/5.6.0/i586-linux
/usr/lib/perl5/5.6.0
/usr/lib/perl5/site_perl/5.6.0/i586-linux
/usr/lib/perl5/site_perl/5.6.0
/usr/lib/perl5/site_perl
.
Matthew Pressly
