On 31.08.2005 00:16:05 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > I don't think you missed anything important except maybe your
> > personal opinion how you'd propose to go on. :-)
>
> Ok.
> Step 0: Baseline rules.
> - No new Errors except possibly some sort of a FOPConfigurationError
> (JAXP implementations tend to have an equivalent). Does anybody
> think we need more?
Nope. If this config error is at all necessary.
> - No new RuntimeException descendants, checked exceptions only.
> - Keep exception declarations lean.
> - Don't wrap RuntimeExceptions thrown by lower layers unless
> the wrapper contains essential additional information
> - Think before committing code (this is a test :-).
Uh, yeah. I think I should remember that last one.
> Step 1: Identify subpackages which potentially are of intertest
> as libraries for others and therefore should get their own
> exceptions. Candidates
(everything that goes into Commons) :-)
> - PDF lib
> - RTF lib
> - shall we have a SVG lib, PS lib, etc?
Yes, we shall. See XML Graphics Commons Plan.
> (BTW had anyone a look at the Cairo API?)
Cairo? no. It's not Java, is it?
> - Font metrics, font management. Oops, already outsorced.
> - Hyphenation
> - Word parsing for hyphenation
> - Data structure underlying the pattern hyphenator (may be reused
> for automatic ligatures)
> - URL handling
> - Unified Image handling API. I hope we aren't reinventing JAI.
> - Image cache
> - Colorspace handlung (not yet implemented)
> - Various Unicode stuff, in particular TR14 and BIDI handling (still
> missing too)
> - Character shaping (also no code yet)
>
> Step 2: Decide how many independent exception trees per package as
> identified in step 1. Proposal
> - Hyphenation gets two Exceptions, one for compiling the patterns,
> one for the actual hyphenation (if necessary)
> - The renderer libraries should probably get one exception tree
> - The smaller utility libs should be ok with existing java.lang
> exceptions and perhaps IOException
> - A FOPException, of course.
> Necessary decisions:
> - Should the Renderer and perhaps the specific renderers (not the
> reusable renderer libs) get their own exceptions? I tend to say
> no, but I'm still sorting arguments.
I don't think, either. Some renderers do a lot of IOExceptions, see my
ugly handleIOTrouble() in PSRenderer.
> - Do we need a FOPConfigurationException?
> - Do we need a FOPConfigurationError?
Depends. I guess ATM we'll need a FOPConfigurationException. I don't buy
the Error, yet.
> - How many exceptions shoudl the font subsystem get (if there's
> something to decide).
As few as possible. Can't tell, yet.
> Step 3: How to use exceptions from the JRE
> - Renderer libs which actually do stream IO should declare IOException
> instead of wrapping it.
Right. But does that mean we add IOException to the throws list of all
the render*() methods (Renderer interface and AbstractRenderer base
class)? Probably the cleanest approach. Since I'm working on the
renderers right now I can immediately start with that if noone thinks
this is bad.
> - Something similar for the image handling API
> - Reusable utility methods taking URLs (as java.net.URL/URI, perhaps
> also as String?) should declare URL related exceptions rather than
> wrap them.
> - Everything else is probably forced to wrap, i.e. no declaration of
> exceptions other than the package specific ones. I don't want to have
> IOExcpetion et al declared in Java interfaces unless the majority
> of the conceivable implementations will throw them.
Ah, more or less answers my question above. :-)
> Step 4: additional exceptions.
> - FOPIOException, and possibly descendants, for wrapping IOException
Really???
> - FOPPrintException, for wrapping PrintException thrown by the
> print renderer. Print renderer users are likely to want to catch it.
More likely for that to happen than for IOException.
> - Does anybody ever catch a PropertyException? It may still
> be useful due to the code. I also think at least some instances
> of PropertyException are thrown because of validation problems.
> We might want to split it into a subclass of ValidationException, a
> PropertyExpressionParseException and a
> PropertyExpressionEvaluationException.
+1
> - We might want to have other subclasses of FOPException indicating
> specific problems with user supplied data, similar to
> ValidationException.
Yes, LayoutException.
> - If there is some code repeatedly used in setting up a FOPException,
> this may point to another FOPException subclass.
> - It may be an idea to have a subclass of FOException which has a
> Locator (or another location indication) and others which havn't
> (i.e. exceptions thrown by renderers). Is it always possible to
> pinpoint the FO which is related to a particular exception? There
> are certainly problems where this is difficult due to asynchronity
> or buffering, like "sample.foo:13: no space left on device".
Well, we don't have location info when the FO comes in as a result of an
XSL transformation. And no, I don't think we can always provide good
location information for all sorts of error conditions. But we may want
to provide as much context information as possible. The error messages
should also be designed carefully so they are very easily understandable.
Did I mention I18N? :-)
> - We might want to have separate exceptions indicating real bugs rather
> than problems with user supplied data or ressources:
> * FOPNotImplementedException indicating known deficiencies
> * FOPInternalException thrown in "can't happen" branches
But aren't those subclasses of RuntimeException which you ruled out
above????
> Some additional thoughts: There are basically two reasons for building
> an exception tree:
> 1. Code reuse, standard OO staple.
> 2. Catching specific exceptions.
> An example for the second: Imagine
> catch( FOOException e) {
> Throwable cause = e.getCause();
> if (cause instanceOf IOException) {
> notifyUser(cause);
> } else if (cause instanceOf BarException)
> ...
> }
> vs.
> catch(FOOIOEXception e) {
> notifyUser((IOException)e.getCause());
> }
> catch(FOOBarException e) {
> ...
> }
>
>
> Step 5: Miscellaneous
> - The RTF lib exception should derive from Excetion rather than
> IOException. Add IOException as necessary. Yes, this hurts.
> - Do something about PDFFilterException.
> - Should we use IllegalArgumentException for sanity checkings
> in the public API classes (not FOTree, layout or anything deeper
> down), e.g. for enumerations for renderers which aren't known?
> I'm undecided. Some JRE packages do so.
Yes, please. Also NullPointerExceptions with reasonable error messages
for null parameters which mustn't be null.
> That's all for today
Thanks so much.
Jeremias Maerki
