Hi. > > [...] > > I think what Luc is suggesting is that by introducing > MathUserException in 2.2 without a material compatibility break > (i.e. nothing that would actually break any 2.1 code) we could set > users to start doing this work incrementally before 3.0 is released. > That seems like a good idea to me IIUC what the impacts are.
Exceptions that are checked in 2.1 (e.g. "FunctionEvaluationException", "DerivativeException", ...) would become unchecked in 2.2, as they'll inherit from "MathUserException". Isn't that a compatibility break? > >>>In 3.0 it will clear that they *have* to do it while, in 2.2, you would > >>>have to explain to users that it's better that they do it but that it > >>>will still work if they don't... And they will probably say: "If it ain't > >>>broken, I won't fix it." ;-) > >> > >>However, deprecation warnings are a strong hint that failure is > >>imminent, and they may wish to prepare for the change. > > > >Yes. We should advertise the list of exceptions that are going to be > >replaced by "MathUserException" when users switch 3.0, by deprecating > >them in 2.2. > >The preparation is to have a perl (or sed or ...) script ready. > > > I think we all agree on the deprecations. I understand your view, > Gilles, that Luc's suggestion does not reduce work for those > upgrading to 3.0; but don't you agree it would be helpful for them > to be able to start - even just with new code they are developing - > using the new user exception, assuming we can introduce it in 2.2 > without breaking anything? > > Luc / Sebb - can you see any real backward compat issue? Would this > change force a recompile? Where, in 2.1, the compiler would have enforced "throws" clauses or catching the checked exceptions, a recompilation would not. And, still, the binaries would be compatible? If that's the case, and you all think that that way is an easier upgrade path, I really don't mind. Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
