I feel that OM classes should only throw Runtime exceptions. The reason is that these exceptions are implementation-specific and so exposing them in the interface binds that interface to the implementation detail which is a Bad Thing. The code which uses OM needs to be able to be completely agnostic of implementation of that OM. I believe there is a good reason to declare a checked exception if it makes a clear sense from "Business Logic" point of view. And in the case of torque it is not (most of the time anyway). Currently the situation is that code using torque has to catch all exceptions from it and, since it has no idea of the nature of those exceptions, the best it can usually do is wrap them into RE and rethrow. I guess a runtime exception would do much better here with the same result. Another related problem is that often I would like OM classes to implement my BL interfaces and I may not do it directly because OM method declares an exception which method in the interface does not, so I have to use various tricks...
I guess I am making sense here. Let me know if you disagree and do not forget to include the reason why. :-) -- fedor. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 20, 2002 6:17 AM > To: 'Turbine Developers List' > Subject: [vote] Standardizing OM for throwing TorqueException > > > I'm about to start porting the OM for throwing > TorqueException instead of > Exception. This change should be 100% backward compatible, because all > existing client code which is catching Exception will also catch > TorqueException. > > My initial goal was to modify only the OM classes (by modifying the > velocimacros), since it's the part that is the most exposed to users. > > However, after much consideration and browsing through the > code, I realized > that if we go up to the source and also modify the BasePeer and Torque > classes, we will get much cleaner code all the way down > through the OM. > > Since BasePeer and Torque are presently throwing Exception, > we would have to > wrap those exceptions into TorqueException from within the OM classes. > > However, if BasePeer and Torque were modified to throw TorqueException > instead, we could just let those exceptions flow through the > OM classes, > which would make the code cleaner, and avoid excessive > exception wrapping. > > I know those two classes are really the corner stone of the > framework. But, > theoritically, this should also be 100% backward compatible. > So it's really > yours to decide whether they should be modified in this action item. > > [vote] > Should BasePeer and Torque classes be modified for throwing > TorqueException, > in addition to OM classes? > > Best Regards, > > Mathieu Frenette > Software Architect > Freeborders Canada > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
