[Dbix-class] DBIx::Class::Validation - croak's With The Validation Result..?

Skye Shaw skye.shaw at gmail.com
Wed Feb 9 20:02:25 GMT 2011


2011/2/8 Peter Rabbitson <rabbit+dbic at rabbit.us>:
> 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?



More information about the DBIx-Class mailing list