Re^3: Non-fatal error handling with Mouse types?

Replies are listed 'Best First'.
Re^4: Non-fatal error handling with Mouse types? by wanna_code_perl (Friar) on Oct 02, 2019 at 13:03 UTC
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.	[reply]
Re^5: Non-fatal error handling with Mouse types? by Your Mother (Archbishop) on Oct 02, 2019 at 14:02 UTC
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.	[reply] [d/l]
Re^6: Non-fatal error handling with Mouse types? by wanna_code_perl (Friar) on Oct 02, 2019 at 14:16 UTC
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.	[reply] [d/l]
Re^7: Non-fatal error handling with Mouse types? by Your Mother (Archbishop) on Oct 02, 2019 at 14:21 UTC
Re^8: Non-fatal error handling with Mouse types? by pryrt (Abbot) on Oct 02, 2019 at 16:09 UTC
Some notes below your chosen depth have not been shown here
Re^8: Non-fatal error handling with Mouse types? by wanna_code_perl (Friar) on Oct 02, 2019 at 15:21 UTC
Some notes below your chosen depth have not been shown here
Re^5: Non-fatal error handling with Mouse types? by 1nickt (Canon) on Oct 02, 2019 at 13:45 UTC
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.	[reply]
Re^6: Non-fatal error handling with Mouse types? by pryrt (Abbot) on Oct 02, 2019 at 16:14 UTC
Sorry, I don't know what that notation means. This part, I can help with on the technical end. Those are logic symbols, often used in mathy-circumstances (as opposed to specific programming language implementations and operators): see List_of_logic_symbols.	[reply]