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
