If when a consumer of your class calls a function with a bad value, you don't want to raise an exception, then I don't understand why you are using type constraints.

I want to constrain some inputs (A). And I don't have an exception-based error model (B). I believe the misunderstanding is that I have A ∧ ¬B, but you've just argued A → B. I already have a normal OO version of the same class that constrains said input types and works just fine without exceptions, so clearly ¬(A → B). I'm really just here for some help with Mouse.

It also sounds off to me. Fatals—or undef with warnings, or returning an objectified error—are the proper action for a broken object. Returning a broken/useless object with an “error state” included seems like a worst practice to me.

Sorry, I don't know what that notation means. I see from your previous threads that you know what an XY problem is so I imagine you are sure that using type constraints where the type is not actually constrained is not barking up the wrong tree. It is however contrary to the standard use of constraints, hence the solutions you have found acceptable are limited to further abusing the tools you have.

Maybe you wish to conform the provided values to a range of acceptable ones instead? Perhaps you could make use of coercions in conjunction with your constraints in that case.



The way forward always starts with a minimal test.