On Saturday 04 January 2003 15:59, Jeremias Maerki wrote:
> Hi Joerg
Oops! Sorry, I should have checked twice before committing to the
wiki, of course its not the PS renderer but the TTFReader and PFMReader
which throw CascadingRuntimeExceptions. I admit this makes the case
less relevant.

Also, never say never. I meant: Throw subclasses of RuntimeException
with caution. There is a reason for the "throws" decl. Well it may be seen
a bit devalued if every method throws a FOPException.
Runtime exceptions should in general only be thrown by low-level, technical
and widely used classes, where the user of the class can be reasonably
expected to check the conditions causing runtime exceptions beforehand
(i.e. being prudent enough to avoid them on average), and where a more
specific exception would be seen misplaced in at least some contexts the
class is used. Also, conditions for Runtime Exceptions should be
*deterministic*, i.e. only depend on the context completely under the
control of the user, preferably only dependent on the data passed to the
routine throwing the exception. An IOException is *not* deterministic in this
sense: someone else could have deleted the file the routine is asked to
open in the meantime.
Also, never should a non-runtime exception be caught and a runtime
exception be thrown: (PFMReader.java)
  } catch (Exception e) {
    throw new CascadingRuntimeException("Error
        while serializing XML font metric file", e);

There is always a certain tradeoff when designing which exceptions are
- Unifying each and every exception into one class or into classes of a
  single inheritance tree keeps the "throws" decl short, but then this decl
  respective the exception types (class names) no longer carry much
  information. Duplicating existing exception types into said hierarchy
  (like FOPIOException, FOPFileNotFoundException...) is nowadays
  out of fashion (it was often seen in C++, because there was no common
  IOException there).
  With exception unification you are basically forced to cascade, and
  unwinding the exception cascade may make long and confusing log
- Throwing a lot of unrelated exceptions may cause "throws" decls
  to grow into unwieldy beings. Currently, there usually aren't that
  much unrelated inheritance trees of exceptions, however, using
  more and more libraries of different origin and design this can become
  an issue.
- Throw a RuntimeException. Such exceptions don't need to be declared.
  This can be seen positive: the user *usually* should not be worried that
  something can go wrong. It can also be seen negative: the user is
  deprieved of the information that something can go wrong, and the
  compiler is silenced about this fact.

So, if the input file is not found, what to do?
1. Nothing, just let the FileNotFoundException pass up. Add "throws
2. Catch it and throw an IllegalArgumentException("wrong filename"+...)
   (Ok, stretching credibility, but let's pass it for now). Add nothing
  to the throws decl.
3. Catch it and throw a FOPException("FO file not found"+...).

Pick one, formulate arguments why you picked it and formulate guidelines
to make sure the same answer would be picked in similar situations (for
some definition of "similar").
Also, make up more such examples :-)

> I'd like to go with a mixture of your first and third point.
This means
- Derive a FOPException from avalon.CascadingException.
- Throw *only* java.lang.* exceptions or subclasses of FOPException.
This means:
- the throws decl features only FOPException (or a subclass) and
  java.lang.* exceptions
- each time a method of a class not from a FOP package is called,
  every non-java.lang.* exception *must* be caught and either a
  FOPException (or a subclass) or a java.lang exception must be thrown.
This seams to be a bit too stringent, probably some slack is called for:
- Allow for SAXExceptions.
- Allow for other Avalon exceptions, in particular other subclasses of
  CascadingException. Well, I'm not sure I'd like this, but using more
  and more Avalon libraries (or XML commons or whatever the project
  is currently called) might make this necessary.

Could you describe your model of this mixture in more detail?


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to