Not being very object-orientated, I'd really appreciate the monastery's wisdom on this. What's the correct/best/usual way of handling error returns from a method?
As an example, say I had a very simple class that wasn't much more than a wrapper around the Unix time_t timestamp. I have a constructor that initialises the object to the current time, a couple of methods for returning the time as a string, and the following method for setting the object's value from a (nearly) arbitrary string:
sub from_string { use Date::Manip; my $self = shift; my $string = shift; my $time_t = &UnixDate($string, "%s"); $self->{NOW}=(defined($time_t))?$time_t:undef; return $self; }
If I feed the from_string method something that even Date::Manip can't handle, and then try to call one of the stringifying methods, is the correct thing for it to do to return an uninitialized value?
Would it be better to signal errors in an $object->error method? Or would a return code (as in DBI's $rv = $sth->execute convention) be better?
--
bowling trophy thieves, die!
In reply to How to say 'oops' in OOPs? by Willard B. Trophy
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |