NAME MooseX::Attribute::TypeConstraint::CustomizeFatal - Control how failed type constraint checks are handled SYNOPSIS package Class; use Moose; use MooseX::Types::Moose ':all'; use MooseX::Attribute::TypeConstraint::CustomizeFatal; my %attributes = ( a => "warning", b => "default", c => "default_no_warning", d => "error", ); while (my ($attribute, $on_typeconstraint_failure) = each %attributes) { has $attribute => ( is => 'ro', isa => Int, default => 12345, traits => ['TypeConstraint::CustomizeFatal'], on_typeconstraint_failure => $on_typeconstraint_failure, ); } package main; Class->new( a => "foo", # will be "foo" but will warn b => "foo", # will be 12345 but will warn c => "foo", # will be 12345 but won't warn # d => "foo", # will die, just like Moose does by default ); DESCRIPTION By default Moose will just die if you give an attribute a typeconstraint that fails. This trait allows you to customize that behavior to make failures either issue an error like Moose does by default (this is the default), a warning and keep the invalid value, or falling back to the default value either silently or with a warning. RATIONALE A lot of our existing validation code just warns on or ignores invalid values, whereas Moose will die on invalid values. This makes converting a lot of code inconvenient, particularly code that has values that are supplied directly by the user, usually we don't want the whole process to die if we have some invalid parameter. We're dealing with these in some cases by wrapping a Moose constructor in try/catch, but that only allows us to either construct an object or not, this trait gives us a much more finely grained control over this not an attribute level. Now you can define on an attribute level what should be done with invalid values, we can either throw an error (the default), warn and keep the invalid value, fall back on the default either with a warning or without one. This makes it easy to write user facing code that dispatches directly to a Moose class. If the user provides us with correct values: great! If he doesn't we can just ignore the provided value, replace it with a default, and move on. In other cases you might want to spew warnings when you start getting unexpected values, but you don't want to die and return an error to the user just because some minor subsystem rendering the page is getting a value it didn't expect. ACKNOWLEDGMENT This module was originally developed at and for Booking.com. With approval from Booking.com, this module was generalized and put on CPAN, for which the authors would like to express their gratitude. AUTHOR Ævar Arnfjörð Bjarmason