db4o 6.2 introduces some dramatic changes to how exceptions are handled within the db4o core. db4o was initially designed to "always work" no matter what was thrown at it and therefore it did not throw many exceptions. This has proven to be nice in some cases and problematic in others. In particular when a user would like to know what went wrong so it can be handled in different ways. For instance, if an object can't be saved properly, the user could try changing the object and re-saving. Another common use case is to display a message on a GUI letting the GUI user know what happened. Prior to version 6.2, users did not have to design with db4o exceptions in mind, but starting from 6.2 and beyond, db4o will now throw Runtime/Unchecked Exceptions.
This is a great step forward in terms of usability for db4o providing immediate feedback of problems and enabling new features such as Unique Constraints (also included in v6.2). Unique Constraints allow you to specify that a particular field must be unique across all instances of a Class. The reason this feature can now be implemented is because db4o can now throw a Unique Constraint Exception that will show exactly what constraint was violated along with the violating object and value.
How will this effect you?
First of all, version 6.2 is a development version so you should not use it in a production environment; use the stable 6.1 release for production. If you are in the early stages of development, it would be a good idea to start using 6.2+ so you will not have any upgrade problems later on.
When upgrading from a previous version of db4o to 6.2+, you should do thorough testing of your application so you can make sure you're catching these new exceptions and handling them appropriately. In particular, you should catch exceptions thrown by ObjectContainer.commit().
try {
// do stuff
oc.commit();
}
catch (RuntimeException e) {
oc.rollback();
throw e; // or display error message
}
If you want to catch all exceptions from db4o, you can catch Db4oException. All exceptions thrown from db4o will will be subclasses of Db4oException.
Another important change to be aware of is that all fatal errors will throw directly out of db4o, for instance OutOfMemory Errors.
The exception handling effort is an ongoing task and and you can watch the progress on this JIRA ticket.