It's definitely not my standard way of operating. But it made sense in this case, and I'm hardly the first person to do it this way. In fact: https://perldoc.perl.org/perlmodstyle.html#Error-handling-and-messages:
Error handling and messages When your module encounters an error it should do one or more of: Return an undefined value. set $Module::errstr or similar (errstr is a common name used by DBI +and other popular modules; if you choose something else, be sure to d +ocument it clearly). warn() or carp() a message to STDERR. croak() only when your module absolutely cannot figure out what to d +o. (croak() is a better version of die() for use within modules, whic +h reports its errors from the perspective of the caller. See Carp for + details of croak() , carp() and other useful routines.) As an alternative to the above, you may prefer to throw exceptions usi +ng the Error module. Configurable error handling can be very useful to your users. Consider + offering a choice of levels for warning and debug messages, an optio +n to send messages to a separate file, a way to specify an error-hand +ling routine, or other such features. Be sure to default all these op +tions to the commonest use.
Returning a broken/useless object with an “error state” included
But that's also sort of the point. I'm not returning a broken/useless object. All of the errors in question are recoverable, and the object is never "broken" or in any sort of undefined state.
In reply to Re^6: Non-fatal error handling with Mouse types?
by wanna_code_perl
in thread Non-fatal error handling with Mouse types?
by wanna_code_perl
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |