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.

In reply to Re: Should a constructor ever return undef? (yes) by grinder
in thread Should a constructor ever return undef? by tall_man

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.