<div dir="ltr">Greetings all!<div><br></div><div>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!</div><div><br></div><div>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 &#39;unsafe&#39; to true within DBIx::Class. I saw there is an &#39;exception_action&#39; available on schema objects. But testing using that turn up &#39;errors&#39; 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.</div><div><br></div><div>And regardless, no matter what I try to do, I don&#39;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&#39;ve tried every combination of documented options I found. Is there really no way whatsoever to change this behavior?</div><div><div><br class="">The HandleError I want to set on connections basically amounts to:</div><div>sub { $self-&gt;add_error($_[0]) }</div><div><br></div><div>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-&gt;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.</div></div><div><br></div><div>To reiterate, my ideal solution allows me to:</div><div>1) Invoke our applications error handling ($self-&gt;add_error()) when &#39;fatal&#39; errors occur.<br></div><div><div>2) Suppress die&#39;ing on SQL errors, so our standard has_error&#39;s checks work</div></div><div>3) Does not require setting unsafe to true, nor block DBIX:Class&#39;s internal use of throw_exception</div><div><br></div><div>Is this possible? If there is documentation or examples we&#39;ve missed, please do direct me to it, and I will RTFM. ;) </div><div><br></div><div>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?</div><div><br></div><div>Much appreciated!</div><div><br></div><div>-Sean </div></div>