Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re: Non-fatal error handling with Mouse types?

by 1nickt (Abbot)
on Oct 02, 2019 at 10:55 UTC ( #11106945=note: print w/replies, xml ) Need Help??


in reply to Non-fatal error handling with Mouse types?

Hi, all the type-validation tools I know raise an exception when the value doesn't pass, and I can't say I've ever needed anything else. How would `error_mode` ever be handed a bad value, since it's only called internally? Would there ever be a case where your code passed a bad value and you didn't want it to croak?

Hope this helps!


The way forward always starts with a minimal test.
  • Comment on Re: Non-fatal error handling with Mouse types?

Replies are listed 'Best First'.
Re^2: Non-fatal error handling with Mouse types?
by Corion (Pope) on Oct 02, 2019 at 11:27 UTC

    I think the issue is more with Moo*'s infatuation with Java-like error backtraces, which are rarely helpful. In most cases you want the bottom-level call within the code you're working with, not the full call stack in the maze of anonymous subroutine helpers that the Moo* family is so fond of.

    Now that I talk about it, maybe a judicious application of Carp's %Carp::Internal could help clean up those tracebacks to a more manageable state?

    #!perl use strict; package foo; use Mouse; use Mouse::Util::TypeConstraints; # Converted to Mouse: enum 'ErrorMode' => qw<carp error both>; has 'error_mode' => ( is => 'rw', isa => 'ErrorMode', default => 'erro +r' ); package main; use strict; use Carp; $Carp::Internal{ 'Mouse::Util' } = 1; $Carp::Verbose = 0; my $foo = foo->new( error_mode => 'silent' );

    This eliminates at least Mouse::Util from the list of the backtrace. Most likely, more of these need to be added...

      Thanks. Indeed, glad I wasn't the only one wondering what the point of those backtraces was. $Carp::Internal would certainly help clean that up a bit, and that's helpful. It's looking like I'd probably also have to do something along the lines of daxim's approach to override Mouse::Util::TypeConstraints->throw_error to make the errors non-fatal.

Re^2: Non-fatal error handling with Mouse types?
by wanna_code_perl (Friar) on Oct 02, 2019 at 11:30 UTC

    $obj->error_mode() would in fact be called externally, and there are several such similar setter subs. The trivially alliterative answer to your second question is "yes". I love exceptions, too, but they were not the best choice for this project.

      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.


      The way forward always starts with a minimal test.

        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11106945]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (5)
As of 2021-01-25 17:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?