You can always code the way you want. Maybe I should have said, “unusual practice that introduces an unfamiliar and fragile error handling pattern,” instead of worst. Perl may be the most ropeful language there is. :P My feedback is 100% intended to help you down the road; and improve the Perlsphere with best practices so it’s taken seriously. I used to bristle at or flat out reject exactly the kind of advice I’m giving so I understand. I feel the bikeshedding implication is unfair; I’m not injecting a personal preference for magenta here and I’m extremely open about my own personal preferences / idiosyncrasies and where they clash with reality.

I'm sorry. I did not mean to imply that you were bikeshedding. The point I did not make very well was simply that I've been in many a lively discussion on error handling, and bikeshedding happens somewhat often.

Nor did I mean to bristle at any of your feedback. More that you're preaching to the converted, and if anything, I'm tired of maintaining this module, but it's apparently too proprietary to publish on CPAN, and I'm apparently the only one left who is any good at Perl. But I digress. :-)

"did not solicit feedback on"

But you did solicit feedback on your attempts to use Moosey type contraints in an update to the code you are undertaking. I stand by my responses; type constraints are for stopping compilation or execution of your program, and if you don't want to stop, don't use a constraint. You mentioned setting $Errstr or similar but that is only done in case of exception: packages that permit the flow to continue use a warning variable. If you want to do that it's of course perfectly fine, but using type constraints is the wrong approach as shown by your attempts and the workarounds you've been provided here.

So my feeble contributions have all been with the intent of helping you with your original question. Sometimes the right answer to "how do I do this?" is "don't."

But, did you look at coercions? Wouldn't correcting a bad value be even better than allowing it? Your coercion can also set or emit a warning if the value needs to be coerced in order to meet the constraint ... ?

I appreciate your advice, really, but by now you must know I already know what you're talking about, and that your advice covers a design decision that was already made several steps back in the development process from where I am today. It's much like telling me I really should go to see Star Wars when I just need to know how to get to the theater for The Avengers tickets I have in my hand. Maybe you're right, and Star Wars is better. And maybe I even agree with you, but my wife bought the tickets online last week and arguing now would be pointless and possibly even bad for my marriage.

Thinking outside the box and looking for XY problems is great. I encourage it, I welcome it. We all need a sanity check now and then. You made your point pretty well eight or nine replies ago, and I'm fresh out of ways to try to either stupidly defend the efficacy of the existing software that I didn't design, or let you know "I agree in general, but my example is specific, and you're ten years and two developers too late for this kind of advice". So I'm not sure about you, but I'm about ready to call it a day and make myself a sandwich. Want one?

Edit: And, sorry I just about missed this twice, but yes, your point about coercions is well made.