Jeremias Maerki wrote:
Cairo? no. It's not Java, is it?
It's C. Nevertheless, it might provide ideas. They can render
2D graphics to PDF.

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.


- 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

The renderer implementation classes (and other FOP specific classes,
if any), should wrap the IOException.

- FOPIOException, and possibly descendants, for wrapping IOException

Dunno. Nevertheless many IOExceptions indicate classic ressource
problems (disk full, connection reset by peer). Note that I/O related exceptions derive from IOException too.

- We might want to have other subclasses of FOPException indicating
 specific problems with user supplied data, similar to

Yes, LayoutException.

I'll check this.

Did I mention I18N? :-)

Horror! =:-0


- 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

I had thought of deriving them from the checked FOPException, but of
course this may cause exception declarations on methods which don't
need them for other purposes. Possibly lots of them.

Ok, let's search for reusable Exceptions. Well, not all of the
exceptions provided by the RTL are apparently supposed to be reused.
Some clearly are (IllegalStateException, Illegal ArgumentException),
because other Java packages do so.
There we find java.lang.UnsupportedOperationException. On of the JDK
docs I read suggested it was part of the container framework, which
might hint on not reusing it. But then, Java 1.4 derives a
java.awt.HeadlessException (funny name: imagine beheaded exception!),
so we might use it as well. There are also java.lang.InternalError
(might be applicable to "can't happen" tests) and
java.lang.UnknownError. Well, they are errors and using them might
cause even more programmers to catch Throwable instead of Exception
(with possibly bad consequences).

The more I think of it, the more I'm inclined to derive
FOPNotImplementedException and and FOPInternalException from RuntimeException, or possibly using a FOPRuntimeException for
both purposes.

Side note: From the 1.4.1 Java docs
  MissingRessourceException: Signals that a resource is missing.
Wow, talk about a comprehensive documentation.

I also noticed that designing the exception system naturally leads
to thoughts about logging. Logging is used for different purposes:
- Indicate progress
- Log warnings, which indicate the output may differ from the output
 of other FO processors. This may be caused for example by
 implementation choices because of the spec is ambiguous or left
 it explicitely to the implementation.
- Log errors which have been ignored or warnings which are actually
 errors (bad input, ressource problems, ...) which have been recovered
 from. The output may to be different from what the user expected,
 or not (an example being the infamous page-number-format="1", which
 formally *is* a syntax error).
- Log information or warnings that something happened which the user
 likely didn't expect, or tells him he is about to shoot himself into
 the foot (for example using a proprietary extension, a legal but
 commonly misunderstood construct, or a deprecated feature).
- Debugging, mainly for developers.

I'd like to throw some ideas onto the list:
- Have some sort of progress() method on the user agent for indicating
 layout/rendering progress.
- Have a warning() , error() and fatalError() method on the user agent.
 Provide a mechanism so that the user can turn recoverable errors and
 warnings into fatal errors, preferably individually.


Reply via email to