As for your abstract class issue, you can always make the error sub an anonymous code reference which just *happens* to default to \&Carp::confess but can be set to whatever makes sense in the application. (For a GUI you probably want to write a log, pop up a pop-up window, and then throw an exception internally? I don't have a sense for what makes sense since I have not worked with GUI code for a long time.) If you do that I would make sure that it is everywhere exported from the same place so it can be switched globally as appropriate.

For your code example, when I write code following a general pattern like that, normally I don't want to make that a silent error. It is too each to have a typo in the list of attributes, I have made mistakes like that a million times. But still if I wanted to make that kind of logic clear, I would suggest creating a method called, "has_attrib" and then calling that in your loop. In fact you can now write it as:

foreach my $object (@object_list) {
  foreach my $attribute_name (grep $object->has_attrib($_), @attribute
+_list) {
    my $value = $object->get($attribute_name);
    # Do stuff here
  }
}
[download]

Finally the EAGAIN is not meant as a counter-example. It is just the specific example that really got me thinking about the basic issues with error-handling logic. In general error-handling logic is the least tested logic in our code. Yet it is the logic which we most depend on working when things goes wrong. Therefore error-handling policies that make error information available and scatter the handling of errors to user code is practically a guarantee that when things go wrong we will not have handled it well.

But here is the EAGAIN issue explained. A very large number of Unix system calls have a possible error that they can return called, "EGAIN". This error means that something was temporarily unavailable, but if you try the call again in a bit, it will probably succeed. A typical example is that fork can fail this way if the OS has run out of process IDs. It is also used to resolve various race conditions. Etc.

Under normal conditions this error is rare to very rare. User code is supposed to test for it and have appropriate failure/retry logic, but people frequently don't write this logic, or they write it but it is buggy, and it never gets exercised. However the odds of the kinds of races that return this error rise dramatically when the system is under heavy load. Therefore if there is a sudden spike in usage that lasts for a while, processes that have been running for ages may start acting up in a variety of bad ways for no apparent reason.

Anyways I didn't mean to compare EAGAIN to the mechanics of your application. I just wanted to point to it as an example of why I think that error logic that has been moved to user code - no matter how clearly documented - is going to become error-prone.

(PS: The system headers you talked about? Some people definitely complain about that. In fact changing how Perl handles errors that come from system calls are on the top of the list of things that Larry Wall wants to change in Perl 6...)

Wow. This is turning into an actual conversation. (Something I've found can sometimes not materialize on PM, unfortunately.) Let me respond one at a time.

sub get {
    my $self = shift;
    my $class = ref($self) or wantarray ? return () : return undef;

    # This is just for safety
    local $_;

    my @args = $self->coerce_args('ARRAY', @_);

    my @return = ();
    if (scalar(@args) < 1) {
        if (wantarray) {
            return @return;
        } else {
            return 0;
        }
    }

    foreach (@args) {
        my $key_name = "${class}::$_";
        if (exists $self->{$key_name}) {
            push @return, $self->{$key_name};
        } else {
            push @return, undef;
        }
    }

    if (wantarray) {
        return @return;
    } else {
        if (scalar(@args) == 1) {
            return $return[0];
        } else {
            return \@return;
        }
    }
}
[download]

Ok. So, 35 lines, not 70. It was 70ish at one point, before I managed to condense a whole bunch. You'll notice the amount of checking I do.

There's a huge amount of stuff I want to add to this, such as switching everything to using a dispatch table, so that people can define their own handlers for a given action, like retrieving or setting an attribute. One of the major criticisms I've received from people looking at this style of abstract base class is that you're stuck using the exact same functionality for every single attribute in a given class. Well, adding dispatch tables would fix that. And, obviously, the idea you mentioned of having an error handler that someone could override needs to be added as well. Combining both things would both expand and contract the actual "getting" function.

There is an exists() function which does your has_attrib() action. I didn't realize we were going to be talking about my abstract base class implementation. (Please look at 88079 for more info.)

I've never used DBI. From my understanding, a SQL statement using the string "NULL" to represent a null string. That would mean that you cannot realistically store the string N-U-L-L in a SQL DB. However, I haven't seen anyone complaining about that, either. (I could very well be wrong, as I don't work with SQL on a day-to-day basis.)

Irregardless, I still maintain that every API forces you to accept certain restrictions on your allowable data-set that aren't in the base language. In using that API, we accept those restrictions (which should be very clearly stated in the accompanying documentation.)

Yeah, every so often I get into a conversation around here. Always seems to surprise people.

Anyways as I say here I don't personally tend to use get/set methods much for personal reasons. After reading the article that I reference, you might find yourself reconsidering assumptions on OO design as well. But that is neither here nor there.

First some detailed comments. On clear programmer mistakes (calling a method as a function) you are not raising an error. That is an error and should be caught ASAP. Secondly I don't like the overloading of the return value. If I am returning to a scalar the result of getting a list of values, that will work fine until that array only has one element, then my code breaks. DWIM is something I am cautious of. If getting single values works, then single values will come up in scalar context. Thirdly attributes do not play well with inheritance in your model unless everyone is everywhere using your get/set routines. To me that is too restrictive.

About DBI, your understanding is only somewhat correct. If you wish to build a string SQL statement you would use NULL for null and "" for an empty string. However when querying from the database you get NULL as undef. Conversely if you use placeholders as DBI recommends, then you slam an undef value into the execute and you will populate the database with NULL values. In short, undef is Perl's version of NULL and both the native input and output respect that.

Finally I tend to consider APIs that needlessly restrict your data representations as somewhat to very broken. They are, at the least, an area of fragility that can lead to broken code. Certainly I work to avoid that, and I think my code is better for that decision.

Now here is (untested) a fragment of code that corresponds roughly to your get, implemented closer to how I would do it:

use Carp;

sub get {
  my $self = shift;
  my @ret = map $self->_get($_), $self->coerce_args(@_);
  wantarray ? @ret : $ret[0];
}

sub _get {
  my $self = shift;
  my $field = shift;
  exists $self->{"attrib_$field"} ?
    $self->{"attrib_$field"} :
    $self->raise("Object '$self' does not have attribute $field");
}

sub raise {
  shift;
  goto &confess;
}
[download]

Since this is untested, there may be obvious typos. But this fixes all of the issues I identified and does some other things. First of all since raise is a method call, it is overridable. Secondly _get is a method call that can be overridden. Classes that want to have attributes accepted that don't fit with this _get can just write their own method, that then defaults to SUPER->_get. That way they can add things like computed fields.

Basically the watchword here is that if you want to get configurability, insert a method call. Place them roughly where you think people would want "hooks" into what you are doing, and you will get the configurability without having to code anything. An alternate way of thinking about it is that a method call already is a lookup into a dispatch table. So rather than code your own dispatch table that people need to interact with by your rules, just make a method call...