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
thrown:
- 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
entries.
- 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
IOException".
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?
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
