in reply to Stringing method calls

For quite a while I've had writing just such a beast on my to-do list. My plan was to overload the object so that any use other than calling a method on it returned undef.

Along similar lines, I'd like it to be easy to write code where, if you don't bother to check for success, then the module dies for you. But if you do bother to check for success, then the module returns a failure code and doesn't die.

To combine both of the these conveniences means that I need the "invalid object" to die if it gets destroyed before undef was ever returned (if that option has been turned on, which would probably be the default).

If you flesh this out, please let me know so that I can use it. (:

(So part of the plan is for the "invalid object" to record which method failed on which object along with a nice, detailed explanation as to why so there'd probably be one or two special methods on the "invalid object" that allowed you to retrieve these details as well -- and these methods would also disarm the auto-die feature.)

        - tye (but my friends call me "Tye")

Replies are listed 'Best First'.
Re (tilly) 2: Stringing method calls
by tilly (Archbishop) on Oct 11, 2001 at 01:21 UTC
    For the second problem I would just write a small function: 
    sub error_out {
  defined(wantarray()) ? shift : croak("Untrapped error '$_[0]'");
}

    [download]
    and then in your module generously use code like: 
      return error_out($failure) if $failure;

    [download]
[reply]
[d/l]
[select]

      No kidding; that part isn't hard. I only mentioned it because I want to combine the two features and the obvious method you show above doesn't help in that case.

              - tye (but my friends call me "Tye")
[reply]

In Section Seekers of Perl Wisdom