2011/10/2 Phil Steitz <phil.ste...@gmail.com>: > On 10/2/11 7:38 AM, Gilles Sadowski wrote: >> Hello. >> >>> took me some time to figure out what your [1] meant, but I think I got >>> it (or did I?)... I'm a bit on the slow side. >> The first time I saw this quote, it also took me a lot of time to understand >> what they were talking about. Indeed, the mere fact of having a hard time >> understanding it indicates that the quote perfectly illustrates the point! >> :-) >> >>>> +1 also because it is the standard style in Java (for better or worse). >>>> >>>> As I've pointed out somewhere else[2], to avoid an avalanche of exception >>>> classes[3], the default assumption should probably not be that every >>>> concept >>>> embodied in a Java class must have its own set of subsumed exceptions. >>>> Rather, failures are more of a concern that is cross-cutting along possibly >>>> unrelated (algorithm) classes. E.g. even if an operator is not always a >>>> linear operator, couldn't it be that using one or the other could trigger a >>>> "SingularOperatorException" (where the "ExceptionContext" would be used to >>>> more fully describe the specifics of each case)? >>>> >>> I understand that appropriate use of exceptions is in fact a quite >>> delicate design issue, which is far beyond my designing skills, so I'm >>> ready to take anything which sounds good to more experienced people. >>> Only, in the present case, I have a hard time figuring out from the >>> above discussion what *is* the best solution. >>> >>> If I understood correctly, Phil would like to have two separate >>> exceptions, SingularOperatorException and SingularMatrixException, >>> with no inheritance link >> Conceptually, the exception are related; however, as we already discussed, >> it is difficult to make them share an implementation. >> It would have been possible by having (marker) interfaces, but that seems to >> be overkill for something that most of the time ends up in aborting the >> program... >> >>> Gilles leans on the one exception+context side (since a Matrix is a >>> linear operator therefore an operator). So if I understand Gilles >>> correctly, we would rename SingularMatrixException to >>> SingularOperatorException, and throw this exception each time we try >>> to invert an operator in the widest sense (linear or not, matrix or >>> not). I actually like that simple option. Also, I would like to remind >>> you that the present exception does *nothing* but display a standard >>> message (there is no state variable in the present >>> SingularMatrixException). >>> >>> Do you think that the discussion is well summed up? >> Almost (cf. below). >> >>> Or can you think >>> of a better way to implement things? For the time, I see two options >>> 1. Keep SingularMatrixException, add SingularOperatorException > > +1 for the reasons I gave above. > +1 for leaving the "linear" in the other names. > > Phil >>> 2. Rename SingularMatrixException to SingularOperatorException and use >>> it more widely (and possibly move it to a more general package). Use >>> context if needed. >>> 3. any other idea? >> I hadn't thought of it, but in the line of "leaner is better", I like >> number 2. However, in some application contexts, people would probably >> prefer to keep the "Matrix" part of the exception name, thus number 1. >> >> >> Best, >> Gilles >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > OK, I'll commit something along these lines. Thank you everyone for your advice!
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
