I see the underlying problem as the desire to make a system do something the system—Mouse and “type checking” in this case—is opposed to by design and expectation. Sidenote on the stack trace errors: IIRC, stvn, the creator of Moose, and therefore the designer of Mouse, regrets the decision to use full stack errors instead of plain caller errors.
The philosophical problem I have with the possible solutions and workarounds is $useless_broken_object now exists and is true and the only way to know it’s bad data is to check it. That’s like allowing $number = Number->new("a\0s\0d\0f") and then needing to remember to check $number->is_really_a_number. Any error catching control flow one might prefer is possible. This one just feels, to me, to be counter-productive, counter-intuitive, and likely to result in bugs because developers will forget to check object state.
I also should have pointed out that the $DBI::errstr / $dbh->errstr pattern cited—while similar, still different at its root—is pretty universally rejected with { RaiseError => 1 } being considered the best practice and most in agreement that the design of DBI is unfortunate overall.
In reply to Re^9: Non-fatal error handling with Mouse types?
by Your Mother
in thread Non-fatal error handling with Mouse types?
by wanna_code_perl
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |