[Dbix-class] Proper way to suppress die from DBIx::Class

[Sean Quinlan]

Greetings all!

Our application has its own internal exception handling that we would like
to be able to use when interacting with the database through DBIx::Class. I
would prefer to do this in a way that does not require using evals all over!

Currently we have a role used throughout our app to manage db connections,
and it would be simple to add a HandleError to the connection to trigger
our error handling, which works fine for that part in testing. But I would
rather not do something that also requires me to set 'unsafe' to true
within DBIx::Class. I saw there is an 'exception_action' available on
schema objects. But testing using that turn up 'errors' for lots of things
that are really just warnings (from my applications point of view), and not
just the subset of issues that cause a fatal error.

And regardless, no matter what I try to do, I don't seem to be able to
suppress the die! Setting RaiseError to 0 and unsafe to 1 on connection
does not appear to have any impact (though the documentation seemed to
indicate it would). Returning true (or false) from my HandleError has no
impact. Using exception_action with or without adjusting RaiseError or
unsafe has no impact. Setting RaiseError on each resultset request has no
impact. I _think_ I've tried every combination of documented options I
found. Is there really no way whatsoever to change this behavior?

The HandleError I want to set on connections basically amounts to:
sub { $self->add_error($_[0]) }

In the application, while we try to validate inputs up front to limit
potential issues, nothing is perfect. Inside the application, a common
pattern is to test for errors after return from a code branch. Frequently
we simply: return if $self->has_errors. Ultimately our response rendering
examines itself for errors and updates the response for serialization
appropriately. This removes _huge_ amounts of boilerplate. In complex cases
we might execute some code before returning if errors had been registered
(extra logging, queue some later job, etc). Wrapping every db interaction
in eval, just in case, adds bunch of repetitive code that adds no value to
this applications process.

To reiterate, my ideal solution allows me to:
1) Invoke our applications error handling ($self->add_error()) when 'fatal'
errors occur.
2) Suppress die'ing on SQL errors, so our standard has_error's checks work
3) Does not require setting unsafe to true, nor block DBIX:Class's internal
use of throw_exception

Is this possible? If there is documentation or examples we've missed,
please do direct me to it, and I will RTFM. ;)

If not all of the above is possible, are there known stable work-arounds,
or recommended practices, that functionally achieve what I want to do in
perhaps a slightly different way?

Much appreciated!

-Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20141001/84a58ea0/attachment.htm>