On Wednesday, August 27, 2003, at 03:46 PM, Bill de h�ra wrote:
Dain Sundstrom wrote:
Back on point, I agree that we should have our own custom subclasses of the spec exceptions that adds useful information. For example in EJB we should have a custom subclasses of EJBException and RemoteException, GeronimoEJBLocalException and GeronimoEJBRemoteException respectively... don't ask why, spec EJB exception handling just plain sucks. These should carry the application name, EJB name, and primary key if appropriate. This does not get us i18, because standard use will be something like;
throw new GeronimoEJBLocalException(
"Transaction failed to commit",
applicationName,
ejbName,
primaryKey,
rootCause);
It doesn't prevent i18n either.
That is my point exactly; this is a completely different issue. It neither helps or hurts. The example I gave was simple, but don't get me wrong the integration of a parameterized message into the message above is not trivial. Some will argue that it is simple because the extra information are the provided parameters, but that is a simple view of the world. Some parameters may not be used in the exception message and some exception message parameters are not interesting and should not be exposed via getters and setters.
Anyone with an opinion on exception handling and API level exceptions should chew on this if they haven't already:
http://c2.com/cgi/wiki?GeneralizeOnExceptionBehavior
I think Bruce Eckel was on about checked exceptions a while back, but I don't have a link handy. [I also recall Ron Jeffries going head to head with the xp list for nearly a week asking for a good reason for checked exceptions; the list pretty much came up wanting]
Theoretical Computer Science discussions are titillating, but this is engineering. If we go off and create a whole new exception hierarchy, we will have a massive learning curve for new coders, and we will have to come up with a hack to get our new hierarchy to play well with the spec required exception handling system. What I am saying is we get Java and J2EE warts and all.
-dain
/************************* * Dain Sundstrom * Partner * Core Developers Network *************************/
