Bug #43604 for MooseX-Types-Structured: More verbose validation error messages

Wed Feb 25 08:49:09 2009 steve [...] purkis.ca - Ticket created

CC:	steve.purkis [...] net-a-porter.com
Subject:	More verbose validation error messages

Currently, when validation fails you get error messages like: died: Attribute (payload) does not pass the type constraint because: Validation failed for 'MooseX::Types::Structured::Dict[channel,Int,start,Str...]' failed with value HASH(0x9d19c68) at lib/My/Example/Tele.pm line 190 This doesn't help you track down *why* validation failed, which would be really useful for nested data structures, ala: has payload => ( is => 'rw', isa => Dict[ channel => Int, start => Str, shows => ArrayRef[ Dict[ show_id => Int, show_name => Str, category_id => Num, ] ], ], required => 1 ); If I mistype 'start' => 'starrt' it would be nice to have an error like: 'Field "start" is missing"' Or similar.

Fri Mar 06 16:16:42 2009 jjn1056 [...] yahoo.com - Correspondence added

On Wed Feb 25 08:49:09 2009, SPURKIS wrote: Show quoted text

> Currently, when validation fails you get error messages like: > > died: Attribute (payload) does not pass the type constraint because: > Validation failed for > 'MooseX::Types::Structured::Dict[channel,Int,start,Str...]' failed with > value HASH(0x9d19c68) at lib/My/Example/Tele.pm line 190 > > This doesn't help you track down *why* validation failed, which would be > really useful for nested data structures, ala: > > has payload => > ( > is => 'rw', > isa => Dict[ > channel => Int, > start => Str, > shows => ArrayRef[ > Dict[ > show_id => Int, > show_name => Str, > category_id => Num, > ] > ], > ], > required => 1 > ); > > If I mistype 'start' => 'starrt' it would be nice to have an error like: > > 'Field "start" is missing"' > > Or similar.

The latest release (0.08) uses Devel::PartialDump to stringify the reference you get in the value section of the error message. It's a bit better since you can now at least see what's getting passed to the type constraint, but it's not giving you exact details. The way the underlying type constraint system is not going to make this trivial. We'll need some changes to Moose::Meta::TypeConstraint to support this, I think. I'll see if I can find a better way, this also bothers me. In the meantime, the message is somewhat better, but I'm going to leave this ticket open since the real problem isn't really solved.

Fri Mar 06 16:16:42 2009 The RT System itself - Status changed from 'new' to 'open'

Fri Apr 03 20:21:43 2009 jjn1056 [...] yahoo.com - Correspondence added

From:

jjn1056 [...] yahoo.com

On Fri Mar 06 16:16:42 2009, jjn1056@yahoo.com wrote: Show quoted text

> On Wed Feb 25 08:49:09 2009, SPURKIS wrote:

> > Currently, when validation fails you get error messages like: > > > > died: Attribute (payload) does not pass the type constraint because: > > Validation failed for > > 'MooseX::Types::Structured::Dict[channel,Int,start,Str...]' failed with > > value HASH(0x9d19c68) at lib/My/Example/Tele.pm line 190 > > > > This doesn't help you track down *why* validation failed, which would be > > really useful for nested data structures, ala: > > > > has payload => > > ( > > is => 'rw', > > isa => Dict[ > > channel => Int, > > start => Str, > > shows => ArrayRef[ > > Dict[ > > show_id => Int, > > show_name => Str, > > category_id => Num, > > ] > > ], > > ], > > required => 1 > > ); > > > > If I mistype 'start' => 'starrt' it would be nice to have an error like: > > > > 'Field "start" is missing"' > > > > Or similar.

> > The latest release (0.08) uses Devel::PartialDump to stringify the > reference you get in the value section of the error message. It's a bit > better since you can now at least see what's getting passed to the type > constraint, but it's not giving you exact details. The way the > underlying type constraint system is not going to make this trivial. > We'll need some changes to Moose::Meta::TypeConstraint to support this, > I think. I'll see if I can find a better way, this also bothers me. In > the meantime, the message is somewhat better, but I'm going to leave > this ticket open since the real problem isn't really solved.

Just another update to whoever is listening :) 0.10 adds in more details. It returns the error of the failing internal error for one level of structure. For the rest it continues the 0.08 behavior of reporting the entire offending value, so at least you'll be able to eyeball it. It's still not exactly what this should be, so I'm continuing to leave this ticket open. As mentioned in the docs, the returned error messages are good for debugging, not for user returned errors, since this will likely and gradually improve.

Mon Apr 06 06:38:56 2009 steve [...] purkis.ca - Correspondence added

On Fri Apr 03 20:21:43 2009, jjn1056@yahoo.com wrote: Show quoted text

> Just another update to whoever is listening :) > > 0.10 adds in more details. It returns the error of the failing internal > error for one level of structure. For the rest it continues the 0.08 > behavior of reporting the entire offending value, so at least you'll be > able to eyeball it. It's still not exactly what this should be, so I'm > continuing to leave this ticket open. As mentioned in the docs, the > returned error messages are good for debugging, not for user returned > errors, since this will likely and gradually improve.

Sounds like a step in the right direction, thanks. Most of the validation errors we've had are several levels deep, but this will help nonetheless! Will try it out over the next week.

Sun May 09 16:32:14 2010 rafl [...] debian.org - Status changed from 'open' to 'resolved'