Skip Menu |

This queue is for tickets about the Moose CPAN distribution.

Report information
The Basics
Id: 114383
Status: new
Priority: 0/
Queue: Moose

Owner: Nobody in particular
Requestors: ether [...]

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)

Subject: make type validation error message indicate which parent type failed to match
15:33 <@ether> wtf... if I have a subtype of Str, and validate a blessed value against it, shouldn't I get the normal validation failure message for a Str, rather than the message for the subtype? 15:34 <@ether> the Str validation should be checked first before we ever get to the subtype 15:34 <@ether> but instead, I'm getting the "your string doesn't match my expected pattern" error from the subtype 15:34 <@ether> which is very confusing because the pattern *does* match (if I had remembered to coerce to a string first) 15:36 < shadowpaste> "ether" at pasted "weird subtype validation error" (40 lines) at 15:36 <@ether> if I'm missing something, I'm being very dumb 15:58 <@ether> what I'm missing is that the check proceeds perfectly normally, and fails at the right point in the parent tree (a blessed value is not a Value), but the check is done independently of getting the error message, so we have already forgotten at what point it failed. and we always just use the ... 15:58 <@ether> ... subtype's validation failure message 15:58 <@ether> which is kinda bunk IMHO 15:58 <@ether> but oh well 15:59 <@ether> so every error message needs to be "not a <parent>, or <message>" 15:59 <@ether> but this isn't recursive 15:59 <@ether> so in this case all I would get is "not a Str, or ...", but it's not a parent of Str either 15:59 <@ether> it owuld be nice to point out at what level of parentage we failed 16:00 < rjbs> Probably not too hard to sort out, except maybe it is with inlining. 16:03 <@ether> yeah, that's the one that would be hard to do, since we jam all the definitions in together in one sub 16:03 <@ether> :'( 16:04 <@ether> in the case I pasted though, the final subtype doesn't have an inlining.. so we could at least say "not a Str" Here's the repro case: use strict; use warnings; use Test::More; use Path::Tiny; use Moose::Util::TypeConstraints; my $Filename = subtype as 'Str', where { $_ !~ qr/(?:\x{0a}|\x{0b}|\x{0c}|\x{0d}|\x{85}|\x{2028}|\x{2029})/ }, message { "Filename contains a newline or other vertical whitespace" }; my $Str = find_type_constraint('Str'); ok(!$Str->check(path("foo/bar/baz")), 'a Path::Tiny is not a Str'); ok(!$Filename->check(path("foo/bar/baz")), 'a Path::Tiny is not a Filename'); like( $Str->validate(path("foo/bar/baz")), qr/Validation failed for 'Str'/, 'correct validation message for Str', ); like( $Filename->validate(path("foo/bar/baz")), qr/Validation failed for 'Str'/, 'correct validation message for Filename, a subtype of Str', ); done_testing; __END__ ok 1 - a Path::Tiny is not a Str ok 2 - a Path::Tiny is not a Filename ok 3 - correct validation message for Str not ok 4 - correct validation message for Filename, a subtype of Str # Failed test 'correct validation message for Filename, a subtype of Str' # at line 23. # 'Filename contains a newline or other vertical whitespace' # doesn't match '(?^:Validation failed for 'Str')' 1..4 # Looks like you failed 1 test of 4.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to