in reply to How to return errors from my object oriented subroutine

Oh, well, maybe my semantics is off. I don't mean errors in the sense that something unacceptable happened... what I mean is that an email address is not to be considered useable by the system if it fails the above business logic (already used, profane, the person has opted out).

Exceptions are typically used when something prohibits the system from continuing as it normally would, ie, some sort of serious error. I can't see uglying up the calling code by wrapping it in eval blocks and checking $@

Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality

Try this in VI: The Emacs Code Browser (sure to earn me a healthy supply of downvotes... heheh)

Replies are listed 'Best First'.
•Re: Re: How to return errors from my object oriented subroutine
by merlyn (Sage) on Aug 19, 2003 at 18:59 UTC
    Perhaps you have a distorted view of exceptions. I consider the "catch with eval {}" errors thrown by DBI to be a decent design, for example.

    Use exceptions when an error return value from the method call would be either inconvenient or impossible to check for.

    For a constructor, typically an undef value is returned for an exceptional case. For setters or getters, throwing exceptions seem to make more sense.

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

[reply]
Re2: How to return errors from my object oriented subroutine
by dragonchild (Archbishop) on Aug 19, 2003 at 18:59 UTC
    Personally, I consider them signals or messages. That a given message might be indicating that an exception occurred doesn't change the the fact that it's still a message from one subsystem to its caller. In fact, in some of my programming, I use a class hierarchy called Signal::*.

    ------
    We are the carpenters and bricklayers of the Information Age.

    The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

[reply]
Re: Re: How to return errors from my object oriented subroutine
by perrin (Chancellor) on Aug 19, 2003 at 19:58 UTC
    Okay, that makes more sense. In that case I would define a set of constants (although I would use globals for them rather the constant pragma) and use those as return values indicating the result of the test. These would be things like $EMAIL_OK, $EMAIL_PROFANE, $EMAIL_DUPLICATE, etc. The calling class can check them against the return value and take appropriate action.

    if ($email->check_validity() == $EMAIL_DUPLICATE) {
    send_error_page(message => 'that e-mail is already in use');
}

    [download]
[reply]
[d/l]
      I would actually have various tests to determine stuff. 
      if ($email->is_duplicate) { ... }
if ($email->is_profane) { ... }
# etc ...

package MyEmail;

sub is_duplicate
{
    my $self = shift;

    $self->validate unless $self->is_validated;

    return $self->{is_duplicate};
}

# all the others are the same

sub validate
{
    my $self = shift;

    # set some attributes

    $self->{is_validated} = 1;
}

      [download]

      This way, you can check any of the possible error messages and the first time an error is checked, the file will be validated.

      ------
      We are the carpenters and bricklayers of the Information Age.

      The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

      Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

[reply]
[d/l]
      if ($email->check_validity() == $EMAIL_DUPLICATE) {
    send_error_page(message => 'that e-mail is already in use');
}

      [download]
      Now here we have to be careful not to mix display and business logic... this might be fine for now, but lateron if we want different UI's to the same business logic, eg. FTP service instead of web service, the send_error_page would have to be less UI-specific.

      But the focus is on clarifying the API of the email validation function, and I think the example is illuminating for that purpose.

      Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality

      The Emacs Code Browser

[reply]
[d/l]
[select]
        It's an intentionally dumb example to show that we are taking some kind of action based on the return value. In a real app I would never put an error string in-line like that.
[reply]

In Section Seekers of Perl Wisdom