Hi. [Starting from the text below, it seems that my copy of the email was oddly missing some part of Luc's post. Thus continuing from here.]
> >> > >> You are confusing two things: > >> (1) > >> It is bad design to let an exception propagate to layers where it is not > >> appropriate; instead, it should be caught and handled or wrapped (or > >> converted) into a more approriate abstraction before being rethrown. > > > > The point here is "where it is not appropriate". If we consider that at > > each level we should catch everything, just to wrap it and rethrow it > > even if we cannot put any added value, then we are back to what was used > > in Fortran code for 50 years: using error codes and managing them > > everywhere. Exceptions are used because you act on them only at two > > levels: the location where you throw them because it is there that you > > detected the problem, and the location at which you have something > > useful to do with it. It can be simply stopping everything at the top > > level, or it can be wrapping and rethrowing because you have added value > > there. There are many places where it is not appropriate to handle the > > exception, so we must let it propagate. Where did I say, that users *have to* catch and rethrow? If they find it appropriate to let the exception propagate, fine! But they decide. Not the CM developer! You are saying: "We know that FunctionEvaluationException is the right abstraction for you." > +1 > > IMO, that is the fundamental issue here. > > >> [Incidentally, this bad practise is encouraged by the CM localization > >> framework. Luc and you wanted to keep it because it makes a mid-level > >> application's code easier (i.e. skipping the catch/wrap/rethrow at the > >> mid-level and let the low-level exception show its localized message at the > >> top level). Easier, yes, but bad design nevertheless.] > > > > I don't get it. > > > >> (2) > >> Good design implies exceptions that are commensurate with the abstraction > >> at > >> hand. So, there is nothing wrong with a low-level component code generating > >> low-level exceptions. It is not CM's job to take care of converting from > >> its level to the upper level. And if we do it, it will go wrong at some > >> point because we lack the context. > > > > Yes, but a user function is high level and should have high level > > exceptions even if it is called from a low level solver. Indeed, low > > level code can call high level code. Yes almost, just missing one word: [...] a user function is high level and should have high level USER exceptions [...] > >> > >> You only think you can do it because you see it through the eyes of a CM > >> user. > > > > So are we too developer-oriented or too user oriented ? I prefer to be > > user-oriented. That is not the point, as I strongly emphasized in my previous post. Unless you think that it is the role of CM to include a collection of all exceptions that could be useful to someone. In that case, you will not stop at "FunctionEvaluationException". > +1. > > This is where wrapped exception are useful - they provide (or at least > should) provide additional detail for developers. Exactly: If they don't provide additional details, they are useless. > >> CM reports failures, and users should be free to deal with them as > >> they wish: Either let it propagate as is or wrap it in whatever wrapper > >> they > >> like. > >> > >>> The principle that I stated in my earlier post > >>> that exceptions should make sense at the in the context of each API > >>> boundary means that we need a substantive hierarchy that expresses the > >>> concepts appropriate at each level. > >> > >> That's wright. But what you propose does not achieve it because the > >> different levels are not within the same body of code. > >> Exception should either express a specific problem (that's true for the > >> low-level exception in CM) or be high-level abstractions needed inside CM > >> (as, for example, if some algorithm actually need to "catch" a family of > >> failure conditions). > >> > >>> FunctionEvaluationException, like > >>> ConvergenceException, is an example of a basic concept that we need to > >>> keep, IMO. > >> > >> As per all that precedes, we need not, and we should not. > > > > As per all that precedes, some of our users need them and we should > > provide it to them. Will CM be able to serve coffee? Some users need it ;-) > >> [...] > >>> The intent of this "misleading documentation" needs to be preserved, > >>> IMO. User-defined functions should throw MathUserException, [...] > >> > >> This is unenforceable. > > > > Just because it is not unenforceable does not mean we should not suggest > > it to users. Of course we cannot prevent them to throw any unchecked > > exception they want, this does not imply we should give up completely > > and not provide documented exceptions for the ones we expect to happen > > at some place. But CM does not expect these. "Expect" means that it catches it somewhere. If there is a contract which users break, then CM will crash somehow; that's expected. I'm not talking about that. I'm signalling that "MathUserException" and "FunctionEvaluationException" will not be acted on by any CM code. > > Putting a "throws FirstException, SecondException" in an > > API is a valuable information for users, If "FirstException" and "SecondException" are user-defined, you don't give any valuable information, you don't give any information at all: the user knows that these exceptions can occur because it is generated by user code. CM is transparent to these exceptions. CM code doesn't catch them, it lets them propagate to the user-level where the user expects thme and knows how to handle them. > > even if in addition to these > > two expected exception there may be NullPointerException, > > ArrayIndexOutOfBoundException, WeirdUncheckedException1, > > WeirUncheckedException2. We cannot prevent the user to throw any of this > > but we do document what we expect. Show me just one example (in the CM code) of what you mean by "what we expect". > +1 > > >> This is actually the main point: Bloating CM with unused exceptions > >> violates > >> the KISS principle (on the faint hope that all users will be happy with > >> your > >> view of the use CM). > >> > >>> [...] a > >>> subclass of FunctionEvaluationExeption (new name) and the expectation > >>> should be that catching the top level class should in fact prevent > >>> things "blowing up" as a result of function activation. > >> > >> Why should a "MathUserException" be a kind of > >> "FunctionEvaluationException", > >> and only that? > > > > I think there are very few cases of user code that can be provided to > > [math]. I don't understand this statement. > > Functions are used in quadrature, root solvers and ODE solvers, > > and they deserve an exception. Events and StepHandler are used in ODE > > and they could deserve their own exceptions too. There are also visitors > > in the linear algebra API, but somehow I don't think a dedicated > > exception is useful for that, but it could. I have nothing against exceptions that are needed to make CM work. [Sorry for the repetition.] If it's needed it's needed; if it is not, it should not be there. > >>>>>> The current 2_x > >>>>>> code cleverly replaces FunctionEvaluationException but still allows > >>>>>> user functions to throw it and user code to catch and handle it. The > >>>>>> problem is that it replaces it uniformly within [math] with > >>>>>> MathUserException. What might be better would be to replace > >>>>>> MathUserException with something like FunctionEvaluationException > >>>>>> (oops - that name is taken - need something else) and then have the > >>>>>> current MathUserException be a subclass, reserved for user functions. > >>>>>> Most internal signatures would then reference > >>>>>> FunctionEvaluationException2 (just kidding about the name, need > >>>>>> something else), but user functions would throw MathUserException. > >>>>> > >>>>> This seems a good idea to me, and I don't have ideas for a name of the > >>>>> higher level exception. > >>>> > >>>> No, no, no. > >>> > >>> Yes, yes, yes :) See comments above. > >> > >> No, no, no. Ditto. > > > > I hope we can finally come to a consensus. The basic problem is should > > [math] declare some users unchecked exceptions that it never uses by > > itself, so users are encouraged to use them when they want to throw them > > in their code and catch them in their code too without [math] getting on > > the way ? But why do you insist on "encouraging" to do this or that or otherwise? Not only they should do what they want, but we should not confuse them by stating things (that could pass for requirements) that, in the end, CM does not care about. CM will not get in the way, whether they use "MathUserException" or not. Moreover, you are encouraging bad practice, because "MathUserException" or "FunctionEvaluationException" are not specific; thus their own code failures will not be self-documenting. To convey more information, users would have to pass "Localizable" parameters! Will they have to build their own implementation of the localization infrastructure? If they don't, what if they miss some "message"? Do we add it in the CM "LocalizedFormats"? Unmanageable. It's so obvious to me that an implementor of, say, the "UnivariateRealFunction" interface will also create the exceptions that the function can possibly throw... unless he is satisfied with those that exists in CM. My best guess is he will choose what we actually *use* i.e. specific exceptions like "OutOfRangeException", "NotPostiveEXception", etc. Bottom-line is that users won't use what you created for their use only. > > The current status (up to 2.1) is that this feature was > > present. The tally is Gilles is against it and wants to remove it, Phil > > and myself are in favor of it and want to preserve it. It was not a feature. It is not a bug either. It is an issue of self-consistency. Clearly it is not a big problem to have one or two useless exceptions, but why bother? > > [...] Best regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
