Community
Participate
Working Groups
Any non-runtime exception thrown during #preCommit, will get wrapped in a TransactionException, see CDOTransactionImpl.java:2401. This then gets caught in #commit, and wrapped into a CommitException, see CDOTransactionImpl.java:1070. So if the original exception was already a CommitException (as is the case, for example, for CommitIntegrityExceptions), we end up throwing a CommitException wrapped in a TransactionException wrapped in a CommitException :S The concepts 'TransactionException' and 'CommitException' seem pretty redundant to me. But what I like about the former is that it's unchecked. What is or should be our strategy here?
> The concepts 'TransactionException' and 'CommitException' seem pretty > redundant to me. But what I like about the former is that it's unchecked. > What is or should be our strategy here? TransactionException is the historical exception and it is unchecked. Late in the 3.0 cycle I decided that we should force the user to think about expectable problems during commit() processing like concurrent modification, referential integrity violation, lock timeouts, etc. The CommitException is supposed to be thrown only and directly from the client side commit() method. TransactionException should not wrap other TransactionExceptions and possibly not other RuntimeExceptions. I wonder if CommitException could unwrap possibly nested TransactionExceptions or if that would lead to information loss...
(In reply to comment #1) > Late in the 3.0 cycle I decided that we should force the user to > think about expectable problems during commit() processing like > concurrent modification, referential integrity violation, lock > timeouts, etc. I don't believe in forcing a client to do anything. Like all of us, the client programmer will click "Quick fix > Surround with try/catch" (or "Add throws decl" if he's of the orthodox school), and get back to it when he feels the need. > The CommitException is supposed to be thrown only and directly > from the client side commit() method. I suppose by "directly" you mean that it shouldn't be thrown from any methods called from #commit? Then CommitTransactionImpl.java:1070 is the only place in the codebase where CommitEx should ever be instantiated. And it follows then that its not meant to be a base class for any other exceptions. (CommitIntegrityEx currently derives from CommitEx -- my bad.) > TransactionException should not wrap other TransactionExceptions > and possibly not other RuntimeExceptions. That it doesn't do, as far as I've seen. > I wonder if CommitException could unwrap possibly nested > TransactionExceptions or if that would lead to information > loss... I don't think that would lead to information loss, as the TransactionException seems to serve no purpose other than to tunnel the checked exception up the call stack without having to declare it. (IMO a tell-tale sign that we don't actually want checked exceptions, but apparently feel obliged to pay some homage to them.) What I mostly don't get is that you seem to want to retain both the TxEx and the CommitEx. Personally I think the TxEx is more convenient and has been used more consistently. CommitEx's only strong point is its better name.
Moving all open enhancement requests to 4.1
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Moving all outstanding enhancements to 4.3
Moving all open enhancement requests to 4.4
Moving all open bugzillas to 4.5.
Moving all unaddressed bugzillas to 4.6.
Moving all open bugs to 4.7
Moving all unresolved issues to version 4.8-
Moving all unresolved issues to version 4.9
Moving to 4.13.
