Tilly, I don't think we disagree so much. I think we just think of differing situations. I was addressing xdg's concerns which seemed to indicate that string exceptions were getting messy.

I apologize, you pretty much said all of TheDamian's arguments for exception objects are arguments for how to better use them for complex flow of control. I still think that statement is overly generalized and too prescriptive of intention, but perhaps TheDamian does argue for complex exceptional flow control. I do find some of his examples baroque. You may know Damian's intended meaning better than I. I apologize that my comments did not display any of the regard I have for the tilly you have shown here and that they reflected my ungenerous reading of your post. I guess you said "people" and I thought "Hey, I'm a people."

But back to the issue.

When you know the code that is going to handle, or not handle, your exceptions you are not in the situation in which exceptions shine. Exceptions are all about passing control to unknown code.

The problem with object exceptions in Perl is that strings are the traditional default: So your expectation that something fancy is being done is reasonable. And that default makes it problematic for anyone writing a module for general use to use anything else. This will be slow to change until some exception package goes into the core. In the mean time, it is producers of larger applications who will be attracted to exception objects and those producers will be deterred by their relatively good info about what lies up the call chain, and by the need to deal with the string exceptions in modules they may use.

The problem with string exceptions in Perl is that they are tedious and error prone to identify. Strings must be controlled by convention, Perl can help in this control if typed exceptions are used. Strings are brittle and unhelpful when you need to present your user with info that varies with some context far removed from the error. They just don't scale well. It only takes the need to discriminate a single exception from the many to start feeling this problem.

If the optimisation (space?) is needed it is easier to factor exception objects into strings than the reverse.

You and I could probably get by with printing a message and exiting instead of dieing. This would also make explicit that handling was not intended. Using an exception in this degenerate case promotes reusability by being flexible, using object exceptions extends this flexibility. Not using this flexibility is not misleading to me.

Be well,
rir

#! /usr/bin/perl

use warnings;
use strict;

package X;
use Carp;

use overload ( qq{""} => sub { return $_[0]->{description}; } );

sub new {
    my ( $class, $description ) = @_;
    $description = "Exception of type $class occurred" unless $descrip
+tion;

    #no strict "refs";
    #dprint "mutts under class" if ( 1 < @{"$class\::ISA"} );
    #dprint "directly instantiated" if $class eq __PACKAGE__;

    bless { description => $description . Carp::longmess() }, $class;
}

sub caught {
    my $class = shift;
    return $class if ( $class eq ref $@ );
    return;
}


package Eperm;
use base "X";


package main;

sub fail { die Eperm->new() }

fail();
[download]

~

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.