Better handling of constraint failures?

[prev] [thread] [next] [Date index for 2004/08/12]

Folks,

Note: I'm not trying to be a jerk, but I posted this message in slightly modified form at www.perlmonks.org as well.

I've just started using the mindblowing Class::DBI and I have to say it's just about the coolest module ever. 

What I REALLY want to do is find a more elegant way of catching specific CDBI::constraint failures- I've overridden CDBI::_croak in my base class, but the info I get back isn't all that useful.

The %info hash returns a reference to the Namespace object and an example error message is:

Namespace namespace fails 'list' constraint with 'page'

Where "Namespace" is a CDBI subclass, the field is "namespace" and the constraint was: 

Namespace->constrain_column(namespace=>[qw/foo/]);

I can parse this error message, but I fear that I can't rely on the text of the error message in perpetuity and that different constraints may throw different errors now or at some other point in time.

The reason I want to catch constraint failures is because I want the constraint checking to act as my HTML form validation check: If the constraint check barfs, I want to re-output the form with an error message on the field that failed. Without an easy way to know which field failed, this won't be easy. Using CDBI constraints to check form values seems like a pretty good way to not repeat myself. . . but I need to give the user specific feedback about the failure.

Would it make sense to have the %info hash returned in constraint checking return something specific and verbose?  Maybe a hash that's something like:

%info=(error_type=>'constraint_failure',failed_column=>'column_name');

In broader terms- does it makes sense to set a standard for what and how %info will return more detailed error messages? This could be generally useful for handling exceptions.

I'm willing to write and submit a patch. . .

-DJCP