This is the mail archive of the frysk@sources.redhat.com mailing list for the frysk project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: frysk-imports frysk/bindir/ftrace.java frysk/d ...


Hi,

On Fri, 2006-08-04 at 08:53 +0200, Tim Moore wrote:
> I'm sensitive to concerns about verbosity in the code dealing with
> errors; my favorite language has a rich condition / error system and
> doesn't have checked exceptions either. However, it seems to me that the
> TIJ argument focuses on exploding try/catch clauses and ignores the
> alternative: design a reasonable object model for the application's
> exceptions and use the throws declarations for methods intelligently to
> both document possible exception conditions and pass responsibility up
> the call chain. This enforced documentation of possible error conditions
> would seem useful in a system where documentation is pretty scanty, but
> if a harried developer doesn't want to think about it he can just write
> "throws FryskCoreException" or whatever and move on.

The documentation aspect and the fact that the compiler can help me when
writing new code in a large existing framework is why I am a fan of
Checked Exceptions. The main problem I am encountering when trying to
grok and hack on frysk is that there is no clear distinction between
unrecoverable or programming errors and recoverable errors. Since both
of these map onto unchecked exceptions I am often at a loss whether I
made an error, supplied wrong parameters somewhere, or there was are
real error, the process we tried to investigate disappeared.

I do appreciate that the verbosity of the code goes up a little. But the
argument that "a lazy programmer" might just throw away an checked
exception and then it is "gone" doesn't sit well with me. That is why we
have code reviews "heay! why do you just throw away that exception
there?". And the documentation value and compiler helping me detect
error handling conditions do seem to outweigh the disadvantage of a
little extra code for exception handling. Since we have exception
chaining it is even easy to wrap a exception from one domain to another
if it really needs to cross module boundaries.

All that said I do see why introducing checked exceptions is a bit of a
pain. I am currently working in the state machine, and whenever I need
access to the Isa now I need to handle the error condition since none of
the state machine interfaces handle the new TaskException. Refactoring
all interfaces to pass these through is not hard, but does mean a large
change to a lot of the proc code. I am not sure we want that at this
time when multiple people are hacking on it. The alternative is as Eckle
suggest to just turn them all into RuntimeExceptions whenever you don't
know how to handle them. But then we immediately loose all advantages
again.

Cheers,

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]