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.
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]
However I concur that we should not be too strict on coding rules to start with - we need lots of code writing & don't wanna put folks off by being too religious about code conventions. Indeed we should be focussing on ensuring the core container, component model & deployer architecture is right so we can start filling in the J2EE stack rather than worrying too much about the exact layout of the code - we can refactor later.
+1000000 we can refactor later
Of course, but ime it's way easier and more fun without finegrained exceptions.
Bill de h�ra
