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

[Tim Moore <timoore at redhat dot com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Cagney wrote:
> Mark Wielaard wrote:
>> Hi Tim,
>>
>> On Thu, 2006-07-20 at 15:58 +0000, moore@sourceware.org wrote:
>>  
>>>     Throw a TaskException from some methods in Task. This is not a
>>>     RuntimeException, so fix all the affected callers too.
>>>     
> FYI, frysk has been intentionally using RuntimeExceptions. Test coverage
> is responsible for demonstrating that potential exceptions are correctly
> handled and that they can occur.
> 
> <<TIJ: Error Handling and Exceptions: Alternative Approaches:
> Perspectives>> discusses this:
> First, it’s worth noting that Java effectively invented the checked
> exception (clearly inspired by C++ exception specifications and the fact
> that C++ programmers typically don’t bother with them). It has been an
> experiment, which no language since has chosen to duplicate.
> 
> Andrew
When I introduced TaskException I made a fairly conscious choice to
derive it from Exception and RuntimeException. My reasoning went like
this: reading a task's Elf file can provoke various errors, all of which
prevent the creation of the proper ISA object for the task and therefore
prevent the creation of a valid task object; this is a serious error and
needs to be recognized by whoever is trying to create the task, but it
is certainly not so serious that Frysk needs to die. Since the Frysk
code base is becoming fairly complex, using a checked exception here
allowed me to discover what methods should be handling this condition by
using the compiler (I suppose "grep" could be an option also). If
callers above the level of task creation want to swallow the error or
turn it into a runtime exception, that's there choice, but at least I've
given them a tool to do something more rigorous.

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.

As far as using tests to ensure proper exception handling, how's that
going? (Note: this isn't meant to be sarcastic :) I just want to learn
more about the Frysk testing strategy). Without thinking about it too
much or knowing the technology, these kinds of tests would seem to
require an large amount of programmer discipline and time.

Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFE0u7leDhWHdXrDRURAiaVAJ0dzJlt7nwyS18lzI4fEMDiz07oFACcDVkQ
c+/RjvdZ+wk0NQtunWGCPac=
=VHoh
-----END PGP SIGNATURE-----