You don't have to declare the throw clause if it's a RuntimeException. The method signature doesn't have to change.
On 5/5/08, Scott Anderson <[EMAIL PROTECTED]> wrote: > > I don't see > > much benefit to providing a binary-compatible method API that does > > nothing. > > ... > > > Another possibility is to @deprecate the method and have it > > unconditionally throw a RuntimeException telling the developer to > > rewrite using query cache options. > > > Adding a Throws clause to the method would change its signature, thereby > breaking the binary compatibility of the method. It's a good idea, but > it won't solve that problem. :) > > Regards, > > Scott > > > -----Original Message----- > From: Mike Kienenberger [mailto:[EMAIL PROTECTED] > Sent: Monday, May 05, 2008 5:01 PM > To: user@cayenne.apache.org > Subject: Re: Query.setRefreshingObjects(boolean) > > Just to reiterate, I see no problem with axing it entirely. I don't > think we have to nicely deprecate everything since we're now in 3.0 > and it's marked unstable. > > However, we should make the need for change obvious. I don't see > much benefit to providing a binary-compatible method API that does > nothing. As an end-user, I want to see things either work as they > always worked, or be given a clear unavoidable indication that work is > required on my part to fix it. > > Another possibility is to @deprecate the method and have it > unconditionally throw a RuntimeException telling the developer to > rewrite using query cache options. > > On 5/5/08, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > > Actually I was going to do the opposite, but since we've set the > backwards > > compatibility bar for ourselves pretty high in the past, I guess I am > > persuaded to go with deprecated-but-don't-cripple approach. I guess > that > > means also putting a deprecation note in the Modeler next to refresh > > checkbox. > > > > Andrus > > > > > > On May 5, 2008, at 11:36 PM, Michael Gentry wrote: > > > > > > > I'd like to second the opinion that deprecated still works (until > > > removed), but is discouraged from use. I believe that is what > Andrus > > > intends, though, given previous API changes. > > > > > > On Mon, May 5, 2008 at 4:02 PM, Mike Kienenberger > <[EMAIL PROTECTED]> > > wrote: > > > > > > > I guess my problem is that to me @deprecate means "it still works > like > > > > it used to, but it won't work in a future version and it's time > for > > > > you to change your code", but that's not what's going to happen > here. > > > > > > > > That's why if we're not really @deprecating it but crippling it, > then > > > > I'd recommend removing it. Giving end-users the false-hope that > > > > things are working as usual isn't very nice. > > > > > > > > You know the details of this particular situation better than I > do, > > > > though. If you don't think silently doing nothing will affect > > > > expected program behavior, go for it. > > > > > > > > > > > > > > > > On 5/5/08, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On May 5, 2008, at 10:39 PM, Mike Kienenberger wrote: > > > > > > > > > > > > > > > > > > > > > To me, that sounded like you were going to change the behavior > > rather > > > > > > than just mark the method as @deprecated. > > > > > > > > > > > > > > > > > > > > > > I was planning to do both. Although we may decide to be gentle > about > > it and > > > > > deprecate the method, but preserve the functionality (which will > put a > > bit > > > > > of extra maintenance burden on us). > > > > > > > > > > I am leaning towards the first option (deprecate and stop > invoking), > > > > > especially since the nature of the change results in enhanced > data > > > > > consistency, so there won't be any unpleasant surprises. > > > > > > > > > > Andrus > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
