I wanted to build an awesome place for people to discuss module specific issues, but I don't have any more time for this, and there are much better places to discuss Perl-related issues. I'd recommend asking your question on Stack Overflow or on Perl Monks.
If you are looking for a Perl tutorial or Perl-related news, I hope these links will serve you well.
Posted on 2005-12-27 17:57:04-08 by earl
Exception::Class objects in scalar context
I am using Exception::Class and I wanted some clarification. I created a simple exception class like ...
use Exception::Class ( 'MyException', ... };
In scalar context, an Exception::Class object implicitly invokes as_string, which invokes message. If the "throw" call doesn't specify a message, the message method returns $!.

Why was $! chosen as the default, over something like "Generic Exception"? When my program did not catch MyException properly, it printed some unrelated error messages. Also, the results were sometimes non-deterministic. This made it harder to find the original problem. Since I throw MyException explicitly under normal conditions, the value of $! is not an appropriate message for MyException.

Thanks!

Direct Responses: 1541 | Write a response
Posted on 2005-12-30 20:07:25-08 by jdhedden in response to 1515
Re: Exception::Class objects in scalar context
    Why was $! chosen as the default, over something like "Generic Exception"?

I don't know the why, bit the how of it can be seen the module's _initialize subroutine:
$self->{message} = $p{message} || $p{error} || $! || '';
The module's author wanted to put something into message, and opted to at least try to capture $! if the developer forgot it.

    When my program did not catch MyException properly, it printed some unrelated
    error messages. Also, the results were sometimes non-deterministic.

This is because your code's picking up whatever was in $! from whenever it was last set. One workaround would be to undef($!) before any section that might result in an exception being thrown.

A better workaround would be to not use the throw method directly, and to wrap it in another method as I did in Object::InsideOut. I created a die method that adds additional location information to the exception object, and then invokes the throw method. You could create a similar method that checks for message and defaults it to something of your choosing.
sub Exception::Class::die { my $class = shift; my %args = @_; # Check for 'message' if (! exists($args{'message'})) { $args{'message'} = '<unknown error>'; } # Throw error $class->throw(%args); } ... My::Error->die() if ! $success;
Direct Responses: 1558 | Write a response
Posted on 2006-01-03 01:52:28-08 by earl in response to 1541
Re: Exception::Class objects in scalar context
I know there are numerous ways to prevent the undesired behavior. And Exception::Class::die is an interesting workaround. But I just want to understand the reason why the current behavior was implemented. I want to see the author's point of view.
Direct Responses: Write a response