That's the convention in perl. One way to use it is like this,

my $foo = MaybeADirectoryObject->new(@args)
    or die 'No object', $!;
# ...
[download]

The eval {die 'No Object' if $error} with $@ handling is really no cleaner. In fact, eval returns undef if block exit is by die-ing or other trappable error, and can be handled the same as the more direct code above.

Update: I previously had the constructor wrapped in defined, but changed it and the description just as ++ctilmes posted his useful comment.

The big difference between perl and C++ exception handling is that, in C++, catch clauses are the responsibility of the try block, while in perl they are the responsibility of the caller. That is a large conceptual gap, but is not so different in application.

After Compline,
Zaxo

I like simply:

my $foo = MaybeADirectoryObject->new(@args) or die "No object: $!";
[download]

eval() catching exceptions seems more awkward to me.

I would probably carp() instead of print in the constructor.

--
Ilya Martynov, ilya@iponweb.net
CTO IPonWEB (UK) Ltd
Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net
Personal website - http://martynov.org

In the general case I would prefer an exception to be thrown since I find that leads to better code (for some definition of better :-)

The only situation where I would consider undef to be more appropriate is if the module would normally be used in a context where the constructor would be expected to fail - in which case "failure" isn't "exceptional" and might be clearer presented as normal control flow.

As ever YMMV :-)

This is the general problem of resource acquisition. Sometimes you cannot test beforehand to see if an operation will succeed. The only way to know it to go ahead and try it.

For instance, even in your constructor, although you test for the existence of a directory with -e (although personally I would test with -d), you cannot be sure that it isn't deleted or renamed between the time you test it and the time you use it. The chance is vanishingly small, but it is non-zero.

C++ constructors don't make a separation between acquisition and initialisation, and you are soundly flamed in C++ circles if you propose

  foo_t foo = new Foo('/path/to/dir');
  foo.init();
[download]

... the main complaint being that when foo is constructed it's ready for service ("what happens if the client forgets to call init()?" is the common observation).

If a constructor fails, or can only partially initialise the object, there is no out-of-band channel to communicate this fact. To get around this problem was one of the main motivations for adding exception handling to the language.

I quite like the fact that Perl object construction works the way it does; that it doesn't require exception handling in the simple case. Remember the dictum "Perl makes the easy things easy."

You're quite comfortable with checking the result of an open or system (... well... you should be), so it should seem natural that you check the results of creating objects too. With the "do or die" idiom, it's quite easy to get the die part of the code out of the way, much cleaner than checking malloc and open in C, where the error checking drowns out the main action.

_____________________________________________
Come to YAPC::Europe 2003 in Paris, 23-25 July 2003.

Ok, it looks like the consensus of most of the answers is that returning undef is normal. But I'd still like to make it harder for the unwary programmers to forget to check the return. I'm suggesting to my co-workers that constructors that can return undef be named "fallible_new" instead of just "new". That might be a little obnoxious, but it would help prevent bugs.

Ok, it looks like the consensus of most of the answers is that returning undef is normal.

Just because something is commonly accepted doesn't mean it's good ;-)

But I'd still like to make it harder for the unwary programmers to forget to check the return.

You might want to look at using the Fatal module. You can use this to force an exception to be thrown if undef is returned.

However, if returning a false value on failure is actually causing problems for you I would strongly consider moving over to an exception throwing style.

Mail::Sender (the newest version) allows you to specify what kind of error reporting do you want. It can either throw an exception (die), return an undef or return a negative error number. This of course affects all methods of the created object as well. Therefore the caller can use whatever feels best for him:

eval {
  my $sender = Mail::Sender->new({on_errors => 'die', ...});
  $sender->Open({...});
  ...
  $sender->Close();
};
die "Failed to send the email: $@\n"
  if $@;

#or

my $sender = Mail::Sender->new({on_errors => 'undef', ...})
  or die "Failed to send the email: failed creating the object - $Mail
+::Sender::Error\n" 
$sender->Open({...})
  or die "Failed to send the email: $Mail::Sender::Error\n"
...
$sender->Close()
  or die "Failed to send the email: $Mail::Sender::Error\n";

#or
...
[download]

Anyway ... I would not want some object to print whetever error messages it pleases into the STDOUT. I would not want them in the STDERR either, but even that would be better.

Jenda
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
   -- Rick Osborne

Edit by castaway: Closed small tag in signature