Community
Participate
Working Groups
I feel that we should come up with a general exception handling strategy that enables us and our consumers to more easily and more specifically react to exceptional situations. Something in net4j.util could provide a useful and *semantic* categorization similar to what the SpringFramework does with its abstraction layer over SQL vendor specific error codes and SQLExceptions. Careful consideration of checked exception versus unchecked exception should also be part of that strategy.
Maybe we can learn from http://www.jarvana.com/jarvana/view/org/springframework/spring/1.2.9/spring-1.2.9-javadoc.jar!/org/springframework/dao/DataAccessException.html
>I feel that we should come up with a general exception handling strategy that >enables us and our consumers to more easily and more specifically react to >exceptional situations. Making things easier is always a good idea, though I must admit that I do not really get the disadvantages of the current implementation ;) >Something in net4j.util could provide a useful and *semantic* categorization >similar to what the SpringFramework does with its abstraction layer over SQL >vendor specific error codes and SQLExceptions. Do you mean something like wrapping all external exceptions (e.g. store implementation specific exceptions) to something CDO/Net4J specific? E.g. if we discover a network failure we through something like a *org.eclipse.net4j.SomethingWasTerriblyWrongWithTheUnderlyingCommunicationChannelException* instead of providing the native exception from the communication implementation (e.g. tcp, http)?
(In reply to comment #2) > I must admit that I do not really get the disadvantages of the > current implementation ;) Yeah, examples/use cases are always good. One recently came up with fail-over sessions. Their whole purpose can be defined as "recover somehow after network problems". But as of now they can not easily distinguish between unanticipatable network/IOExceptions and those that occur during request processing within the server. I'll think about more examples. Others: please also contribute your (bad) experiences with our exception handling! > Do you mean something like wrapping all external exceptions (e.g. store > implementation specific exceptions) to something CDO/Net4J specific? Wrapping of checked exceptions and exceptions that don't properly aghere to our to-be-specified strategy could be one approach. Please note that this would really involve the wrapping of the native *methods* that throw these exceptions! Something CDO/Net4J specific? It could be the case that we don't find the exceptions classes that we'd need to implement our to-be-specified strategy somewhere outside of Net4j/CDO. But I feel that at first these execeptions should have general applicable semantics, because these would be the terms that users use to thin in. > E.g. if we discover a network failure we through something like a > *org.eclipse.net4j. util. > SomethingWasTerriblyWrongWithTheUnderlyingCommunicationChannelException* > instead of providing the native exception from the communication implementation > (e.g. tcp, http)? Yes.
> One recently came up with fail-over sessions. Their whole purpose can be > defined as "recover somehow after network problems". But as of now they > can not easily distinguish between unanticipatable network/IOExceptions > and those that occur during request processing within the server. Actually I'm not sure this is a good example. IMO, my recovery logic was simply flawed in that it didn't bother to check at all what kind of exception it was handling. I just fixed that by making it check whether it's an instanceof TransportException. Seems to work. (Bug 335830)
> Careful consideration of checked exception versus unchecked exception should > also be part of that strategy. Here's my preferred strategy: don't use checked exceptions. No need for me to explain why cause the web is ridden with such explanations. If you Google for 'checked exceptions' you'll notice that apart from the top 3 or 4 hits, all posts are about why *not* to use them.
(In reply to comment #5) I mostly agree and we almost have no checked exception in Net4j or CDO. Though I feel that checked exceptions are a means to force users to care about expectable problems tat they do have a chance to recover from, e.g. our CMEs from TransactionCommitContext. Just in case you agree, that would bring up the technical challenge to have a whole hierarchy of meaningful, semantic exceptions and make only parts of it checked. E.g. how would our CommitException fit into this picture?
(In reply to comment #4) > Actually I'm not sure this is a good example. IMO, my recovery logic was > simply flawed in that it didn't bother to check at all what kind of > exception it was handling. I just fixed that by making it check whether it's > an instanceof TransportException. Seems to work. (Bug 335830) In fact TransportException is one of the few examples where we do have a meaningful exception class. But what about IOExceptions? I added that question to the bug you mention.
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.
