Do you use an exception class in your Perl programs? Why or why not?

Cross posted on Stack Overflow

I've got a bunch of questions about how people use exceptions in Perl. I've included some background notes on exceptions, skip this if you want, but please take a moment to read the questions and respond to them.

Thanks.

Background on Perl Exceptions

Perl has a very basic built-in exception system that provides a spring-board for more sophisticated usage.

For example die "I ate a bug.\n"; throws an exception with a string assigned to $@.

You can also throw an object, instead of a string: die BadBug->new('I ate a bug.');

You can even install a signal handler to catch the SIGDIE psuedo-signal. Here's a handler that rethrows exceptions as objects if they aren't already.

$SIG{__DIE__} = sub { 
    my $e = shift; 
    $e = ExceptionObject->new( $e ) unless blessed $e;
    die $e;
}
[download]

This pattern is used in a number of CPAN modules. but perlvar says:

Due to an implementation glitch, the $SIG{DIE} hook is called even inside an eval(). Do not use this to rewrite a pending exception in $@ , or as a bizarre substitute for overriding CORE::GLOBAL::die() . This strange action at a distance may be fixed in a future release so that $SIG{DIE} is only called if your program is about to exit, as was the original intent. Any other use is deprecated.

So now I wonder if objectifying exceptions in sigdie is evil.

The Questions

Do you use exception objects? If so, which one and why? If not, why not?
If you don't use exception objects, what would entice you to use them?
If you do use exception objects, what do you hate about them, and what could be better?
Is objectifying exceptions in the DIE handler a bad idea?
Where should I objectify my exceptions? In my eval{} wrapper? In a sigdie handler?
Are there any papers, articles or other resources on exceptions in general and in Perl that you find useful or enlightening.

TGI says moo

Comment on Do you use an exception class in your Perl programs? Why or why not? Select or Download Code

Replies are listed 'Best First'.
Re: Do you use an exception class in your Perl programs? Why or why not? by zwon (Abbot) on Mar 13, 2010 at 21:53 UTC
1. No I don't. I tried to use them, but failed to see how they can make my life easier, and code cleaner and more reliable, comparing to using die. When I'm using eval I usually just want to know if code succeed or failed, I can't remember right now any case where I wanted to perform different actions based on the `$@` content. Some of my colleagues are actively using Exception::Class and, from my point of view, it doesn't make their code better. I just hate to see statements like: `do_something or MyCompany::Product::Subsystem::Module::Exceptions::IOE +rror->throw("Couldn't open $file: $!");` [download] 2. If I will learn how to use exception objects to improve my code quality I will immediately start to use them. 4. Yes, I think generally it is a bad idea. Redefining `$SIG{__DIE__}` may cause some hard to debug problems.	[reply] [d/l] [select]
Re^2: Do you use an exception class in your Perl programs? Why or why not? by TGI (Parson) on Mar 14, 2010 at 01:39 UTC
I've been mostly underwhelmed with exception based techniques and exception objects. Try::Tiny has resolved many of my complaints with exceptions in general, so I am using them again. It bothers me to have to keep writing the likes of: `if( $@ =~ /some error stuff/ ) { warn "error stuff occurred"; } else { warn "some other message" ; }` [download] An exception class system that works would remove the need for parsing data out of strings that should be available in a data structure. I feel like Perl exceptions are kind of like Perl OO in general. The language provides a bare minimum set of features that can be used to get things done, bat can also be extended in clever ways. We have 37 million Class::Foo modules that tried to build a better Perl object system. After years of experimentation, Moose hit the scene and has taken over. Is exception handling in Perl ripe for the introduction of a revolutionary module like Moose? What would it look like? Thanks for your thoughts. TGI says moo	[reply] [d/l]
Re^3: Do you use an exception class in your Perl programs? Why or why not? by zwon (Abbot) on Mar 14, 2010 at 10:14 UTC
`if( $@ =~ /some error stuff/ ) { warn "error stuff occurred"; } else { warn "some other message" ; }` [download] As I said I usually just do `if($@) { Oops; }` [download] but now you mentioned it and I remember one case when I have to examine `$@` content deeper. But usually I'm avoiding this, particularly because I don't see the way to do it clean. I feel like Perl exceptions are kind of like Perl OO in general. I feel that too. The problem is that `$@` may contain any object, there's no standard interface to it. If there will be a module that change this situation, that would be great.	[reply] [d/l] [select]
Re: Do you use an exception class in your Perl programs? Why or why not? by creamygoodness (Curate) on Mar 15, 2010 at 00:03 UTC
I sometimes use exception objects because catching exceptions based on class is less fragile than catching exceptions based on examining the error message. `if ($@) { # Fragile. if ($@ =~ /My error message/) { ... } else { die $@ } # Robust. if (blessed($@) and $@->isa("MyError")) { ... } else { die $@ } }` [download]	[reply] [d/l]
Re^2: Do you use an exception class in your Perl programs? Why or why not? by TGI (Parson) on Mar 15, 2010 at 04:59 UTC
Parsing strings is fragile and error prone. Imagine if we had to pass our subroutine arguments and return values as strings. Without exception objects, that it the situation with exceptions. It really bothers me that I have to parse a string to identify an exception type. Especially since the raw data that produced the string should be available. This is the fundamental reason I've been obsessing about exceptions lately. TGI says moo	[reply]
Re: Do you use an exception class in your Perl programs? Why or why not? by doug (Pilgrim) on Mar 14, 2010 at 23:22 UTC
1. Do you use exception objects? If so, which one and why? If not, why not? No. I prefer to die() or confess() when I hit errors that I can't handle. Why drag things out? 2. If you don't use exception objects, what would entice you to use them? I don't like the idea of exceptions. Instead of handling a problem where you find it, you get an ugly COME FROM mechanism. I find a gazillion try/catch blocks (aka eval/die) to be distracting. 4. Is objectifying exceptions in the DIE handler a bad idea? Dunno. It isn't something I've ever really considered before. - doug	[reply]

Back to Meditations