Exception handling

When an exception occurs (for example a constraint on a column is violated), the application exits. This is unacceptable in many circumstances. One way round this is to eval each call to $obj->update and __PACKAGE__::create, but this is not always feasible, especially when migrating a legacy app to Class::DBI's object model.

Using Error and _croak (as described in the docs) are not a good solution either since Class::DBI expects _croak to throw an exception and will happily fill the void if none is thrown.

IMO, this is a broken design. The app should not be forced to exit if a constraint is not met, since there is a strong possibility that the app can fix the broken data and meet the constraint. What should occur is the create or update returns undef</tt> and the original data remains unchanged; $@</tt> can be used to contain the text of the exception.

This is bad because one non-eval</tt>'d update can bring down the entire application if the data does not meet the constraint. This is bad in any case but in a web app it is utterly disastrous (consider a user entering an invalid age, e.g.).

Do any workarounds exist?

--

This isn't broken - the application needs to handle the situation though. There are several ways to do this: from the web, javascript is excellent for checking input (to reduce the user waiting time for an error response from the server). Column validation should in any case be carried out (server side) before sending data to the database - this is where the eval should catch the error and _not_ update the object unless it is valid.