Hello Fedor! I understand the essence of what you're saying, however I have to disagree ;-)
I agree that, indeed, it would make life a little easier for cases where the application doesn't need to recover from those exceptions. However, in many cases, when the application needs to be fail-safe, those exceptions must be caught correctly. So we would end up catching Exception or RuntimeException anyway. I also disagree with you saying that this would expose the implementation. All the contrary. Having everything throw TorqueException would create a clean API which totally hides its underlying implementation. All well designed APIs have this kind of high-level exception. Instead of exposing implementation-specific low-level exceptions, it rather hides them behind an higher-level exception. And this doesn't bind the client code to the API more than it is already. As soon as some code is using an API, it is bound to its interfaces (be there exceptions or not). We simply cannot avoid binding client code to an API that it uses (unless you create an additional abstraction layer). However, our job is to abstract the implementation of an API from the interface of this API. And, as long as exceptions are concerned, this is the job of a high-level exception, such as TorqueException. As it is now, catching Exception doesn't ensure that the codes catches only Torque's exceptions. Not at all. In fact, it catches everything, including run-time exceptions, such as NullPointerException, which should generally not be recoverable at all. And those exceptions might not even come from Torque, but maybe from portions of client code that make calls to Torque. Now imagine that someone really requires a fail-safe application. He wants to catch all Torque's exceptions, but only those. The only way to achieve that is to check Torque's implementation, determine all the possible exceptions that it may throw, and catch all of them individually. Ugly. But, in addition to being ugly and cumbersome, this *does* totally expose the implementation of the API. My point is not that RuntimeException is bad (even though in many cases it is lazy! ;-). Rather, my point is that a high-level exception (such as TorqueException) is much better than a base exception (such as Exception or RuntimeException). In fact, having the API throw a TorqueRuntimeException would be OK. It would be better than throwing Exception, because it would allow for both approaches (either letting exceptions fall through, or catching Torque-specific exceptions). However, in this particular case, a checked exception would be even better, because exceptions originating from Torque should be recoverable, and that's exactly what checked exceptions are for. A good reference in this matter is Joshua Bloch (an engineer in Sun's Core Java Platform Group) in his book "Effective Java". Let me cite him here: "To avoid [the problem of exposing implementation details through exceptions], higher layers should catch lower-level exceptions and, in their place, throw exceptions that are explainable in terms of the higher-level abstraction. This idiom, which we call exception translation [...]" (p.178) and: "Use checked exceptions for recoverable conditions and run-time exceptions for programming errors" (p.172) In my opinion, Torque throws recoverable exceptions. And I think this takes a much greater importance when designing a major API like Torque. Well, that's my (not so concise) opinion! Hehe! ;-) Best Regards, -- Mathieu -----Original Message----- From: Fedor Karpelevitch [mailto:[EMAIL PROTECTED]] Sent: February 20, 2002 11:19 AM To: 'Turbine Developers List' Subject: RE: [vote] Standardizing OM for throwing TorqueException 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
