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.
[download]

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.