It represents approximately 45 mins to 90 mins worth of work. With a good IDE it's easy, however the changes are scattered in many files, mostly in extending OM classes. I did the work for fixing Scarab (not officially, just on my local machine, to determine the impacts) and I'm almost done. My only concern is when an exception is thrown from an extending class. For example, many of Scarab's extending classes throw a ScarabException (deriving from Exception). Those exceptions were allowed, because of the "throws Exception" statement, but are no longer allowed. So they now have to be wrapped into a TorqueException. This can be done quite easily right from within the extending classes. However, the real question is: are those ScarabException caught as ScarabException or as Exception in the client code that uses the OM? Because if we wrap them, the catch blocks in client code may no longer work as expected. I'll try to figure that one out, but I think that we should ask Scarab's people about it. What do you think?
PS: If Scarab's people need help fixing their code for this issue, I'm willing to participate. Regards, -- Mathieu -----Original Message----- From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Sent: February 22, 2002 5:13 PM To: [EMAIL PROTECTED]; turbine-dev Subject: Re: [PATCH] Standardizing OM for throwing TorqueException How much breakage are we talking about? If it is difficult to fix Scarab, then we should probably branch Torque. If it is easy, then lets just make the changes. Another change we need to make to Torque is to have it return List instead of Vector. :-) That should break lots of code. :-) -jon on 2/22/02 9:15 AM, "Mathieu Frenette" <[EMAIL PROTECTED]> wrote: > Thanks Jon for the great idea. > > I rebuilt Scarab from scratch with the modified Torque and the problems > showed up. > > Here is why... > > We assumed that throwing TorqueException instead of Exception was fully > backward compatible with existing "client" code. However, we forgot to > consider "extending" code. Indeed, if anybody extended a base class and > overrode a method that was throwing Exception, this method is no longer > valid now that its base method throws TorqueException. > > So all extending classes would have to be patched to also throw > TorqueException. This is only required for overriding methods, not for new > methods. But even then, it might represent an important rework for big > projects such as Scarab, which have tens of extending classes with tons of > overrides. > > What's even worse is that, due to the lenient exception model used in > Torque, all extending methods are free to throw whatever exception they > want. But those exceptions cannot simply be wrapped into TorqueException, > because chances are that the client code using the extending classes might > be catching the specific exceptions. > > That means the client code is bound to the implementation details of the OM, > and especially to the extending classes' implementation. That is really > BAD. And that was my whole point when arguing that TorqueException was so > important. Now it seems to be too late. Unless we force people into the > change, which is not a good option either. > > I'm sad about that, not because of the time I put into it, but rather > because of my idealistic mind! ;-) Hehe... > > Any comments, opinions, suggestions would be appreciated... > > -- Mathieu. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
