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

I wasn't planning on chiming in, because I have nothing technical to add. But there seems to be communication cross-purposes here. I think I understand from a high level what wanna_code_perl is trying to get at. Maybe a translation into an (imperfect) real-world analogy will help.

There's a universe-program that has a dog-object. When the dog eats (input data), it normally incorporates the food into the fiber of its being, affecting what it is and how it behaves (data is incorporated into the object's underlying data). When the dog is fed bad food, Your Mother and 1nickt seem to be indicating the right thing to do is to stop the universe from running, and make the local deity restart the unverse, after correcting it so the dog won't be fed bad food. wanna_code_perl wants the dog to start crying (an instance-level "something's wrong with my data" flag), so that this specific dog's owner (some oversight sub-process or a future call to a subroutine or method) will take notice, and take the dog to the vet to have the stomach pumped and an IV of good nutrients started (ie, fix the bad data).

Yes, I understand there are plenty of programming situations when being given bad data is sufficient condition to kill the program; but sometimes, the problems are recoverable, so dying seems overkill.

Moreover, Your Mother seems to be okay with returning "undef with warnings"; wanna_code_perl seems to want the object's state to indicate the problem, rather than just a return value. I don't see how that's fundamentally different. But maybe I've misunderstood something.

To me, it looked like this conversation needed a different perspective/phrasing from the outside, so it could start moving forward, rather than going in circles. If this doesn't provide that, or is a useless misunderstanding or one or both perspectives, sorry. Feel free to ignore.

update: if, as 1nickt said here, error-flags are "...only done in case of exception: ... If you want to do that it's of course perfectly fine, but using type constraints is the wrong approach", then maybe someone could provide guidance on how wanna_code_perl could shift perspective from using type constraints to using something else, to mimic the same flow that already worked, but within the realm of what Mouse and OOP-best-practices makes practical. (tried to get update in before anyone commented on mine.)

Comment on Re^8: Non-fatal error handling with Mouse types? Download Code

Replies are listed 'Best First'.
Re^9: Non-fatal error handling with Mouse types? by Your Mother (Archbishop) on Oct 02, 2019 at 17:01 UTC
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.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^9: Non-fatal error handling with Mouse types?
by Your Mother (Archbishop) on Oct 02, 2019 at 17:01 UTC

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.

[reply]
[d/l]
[select]