Quantcast

DBIx::Class::Validation - croak's With The Validation Result..?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

DBIx::Class::Validation - croak's With The Validation Result..?

Skye Shaw
Hi,

Does anyone find it odd that DBIx::Class::Validation croaks when
validation fails via $obj->validate?

I understand the need to do this on insert & update, but it seems a
little unorthodox writing code like the following just to check the
validation result:

my $result;
eval { $result = $obj->validate };
$result = $@ if $@;

This can become (more) cumbersome if the validation involves querying the DB.

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DBIx::Class::Validation - croak's With The Validation Result..?

Skye Shaw
2011/2/8 Peter Rabbitson <[hidden email]>:

> Skye Shaw wrote:
>>
>> Hi,
>>
>> Does anyone find it odd that DBIx::Class::Validation croaks when
>> validation fails via $obj->validate?
>>
>> I understand the need to do this on insert & update, but it seems a
>> little unorthodox writing code like the following just to check the
>> validation result:
>>
>> my $result;
>> eval { $result = $obj->validate };
>> $result = $@ if $@;
>>
>> This can become (more) cumbersome if the validation involves querying the
>> DB.
>
> This is why you write:
>
> try {
>  my $good_result = $obj->validate;
>  do stuff with good result
> } catch {
>  my $bad_result = $_
>  do stuff with bad result
> };
>

I didn't realize DBIx depends on a try/catch module and didn't know
that these methods were available.

> Or if you "do stuff" the same:
>
> my $result = try { $obj->validate } catch { $_ };
>
> Exception based control flow is very common and very useful. You can't
> ignore
> it or forget about it

I'm not against exception based control by any means. I think this is
not the proper use of such a model.

The purpose of an exception is to let the caller know that the callee
could not produce the expected result. In the case of validate() the
caller expects a  validation summary. Agreed?

Now if the validation summary could not be constructed then an
exception should be called. But, when it's successfully constructed
and contains an error, the result is thrown as an exception. What's
the exception? The caller *wants* the validation summary. In fact it's
the only thing returned by the exception. Why inconvenience the caller
by forcing them to deal with such an arrangement?

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Loading...