Skip Menu |

This queue is for tickets about the Type-Tiny CPAN distribution.

Report information
The Basics
Id: 85149
Status: resolved
Priority: 0/
Queue: Type-Tiny

People
Owner: perl [...] toby.ink
Requestors: xenoterracide [...] gmail.com
Cc:
AdminCc:

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



Subject: exception objects
Date: Wed, 8 May 2013 22:52:23 -0500
To: bugs-type-tiny [...] rt.cpan.org
From: Caleb Cushing <xenoterracide [...] gmail.com>
I think right now Throwable seems like the nicest, I also like Exception::Base, but in any way shape or form it would to support throwing exception objects, ideally with the following settable attributes messsage type name (attr name? could it know this? ) This will allow things like controllers in web apps to better determine what failed and what to tell the user. Not having exception objects for attribute validation is one of Moose's biggest flaws IMO, it makes it next to impossible to tell a user what went wrong (developer sure, but I want to throw nice messages to a user) -- Caleb Cushing http://xenoterracide.com
I don't want to introduce any extra dependencies, but exception classes are easy enough to hand write if you don't need stack traces, so that shouldn't be a problem. If you need stacktraces, you could just do something like: Role::Tiny->apply_roles_to_package( "StackTrace::Auto", "Type::Exception", ); The main reason I've avoided this so far is that for an exception to be useful, you'd probably want to be able to call $e->type to fetch the type constraint object that generated the exception, right? And that introduces difficulties inlining the exception-generating code. But I'll keep this bug open in case I can find a solution.
It's also worth noting that even if Type::Tiny emits exceptions for "assert_valid" and so on, this wouldn't necessarily change the behaviour you see when the type constraint is used for a Moose/Moo attribute. Moose throws its error by calling the type's "get_message" method, interpolating that into a string, and then confessing that string. Moo catches whatever error message the type constraint tries to throw (using $SIG{__DIE__}, not eval), and concatenates that with another string, then dies with that string. In both cases, an exception object wouldn't survive the OO framework's post-processing.
Subject: Re: [rt.cpan.org #85149] exception objects
Date: Thu, 9 May 2013 10:20:27 -0500
To: bug-Type-Tiny [...] rt.cpan.org
From: Caleb Cushing <xenoterracide [...] gmail.com>
I'm also referring to the behavior of Type::Params which would not be affected by Moose/Moo/etc Although all kinds of conveniences are needed, the biggest probably has been figuring out which attribute/what type got thrown (names, not necessarily the validation code itself as I'm unlikely to return class/regex to a UI). Parsing strings is problematic at best. Even if Moo/Moose were still failing it might be a step towards making them better (they need a new type system IMO) you wouldn't necessarily have to add a dependency, rather support an interface. Dependency Inversion Principle. Internally it might look something like this my $obj = $class->new( message => ..., ... ) $obj->throw() How you might let it be used (note: I don't really like doing this in an import statement, it makes it hard to inject the type validator) use Type::Params compile => { class => 'Throwable::Error' }, validate => { class => 'Exception::Base' }, ; even better might be something like this, which would be really easy to inject into my objects at runtime state $check = Type::Params->new( compile => { class => 'Throwable::Error' }, validate => { class => 'Exception::Base' }, )->compile( ... ); ultimately it would allow me to write stuff like package Test { use Moose; has _validator => ( ... ); } Test->new( _validator => Type::Params->new( ... ) ) which could be done by something like Bread::Board, and now I too am simply coding to an interface. On Thu, May 9, 2013 at 8:38 AM, Toby Inkster via RT <bug-Type-Tiny@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=85149 > > > It's also worth noting that even if Type::Tiny emits exceptions for "assert_valid" and so on, this wouldn't necessarily change the behaviour you see when the type constraint is used for a Moose/Moo attribute. > > Moose throws its error by calling the type's "get_message" method, interpolating that into a string, and then confessing that string. > > Moo catches whatever error message the type constraint tries to throw (using $SIG{__DIE__}, not eval), and concatenates that with another string, then dies with that string. > > In both cases, an exception object wouldn't survive the OO framework's post-processing.
-- Caleb Cushing http://xenoterracide.com
Currently working on a branch for exceptions. So far, the following code works: use v5.12; use Data::Dumper; use Try::Tiny; use Types::Standard -types; try { my $ArrayOfInt = ArrayRef[Int]; $ArrayOfInt->assert_valid([1, 2, "Hello"]); } catch { say $_->isa('Type::Exception'); # 1 say $_->type->display_name; # ArrayRef[Int] say Dumper($_->value); # $VAR1 = [... }; You can also call $_->explain on the exception object to get quite a detailed explanation of why the assertion failed. In the above example the explanation would be the following arrayref... [ '[1,2,"Hello"] fails type constraint ArrayRef[Int]', 'Int is a subtype of Num', 'Value "Hello" (in $_->[2]) fails type constraint Num', 'Num is defined as: (!ref($_) && Scalar::Util::looks_like_number($_))', ]
Type-Tiny 0.005_03 includes exception objects.
Type-Tiny in the repo now has no usage of Carp.pm at all; everything is exceptions. There are only three specialised exception classes; most others are just generic Type::Exception objects that report a message and line number. But the three specialised classes should cover most of the more interesting exceptions.
0.006 is now out, with exceptions.