Propigating Exceptions Through APIs

[Alan Gutierrez]

I'm writing an XML document object model that is paged. It is
not meant to be used directly by application developers, but
through one of the DOM APIs or through an engine like XSLT.

Since it is file based, rather than in memory, there are plenty
of places where IOException is thrown from java.io.*.

Since it is supports concurrent reads, there a are plenty of
places where InterruptedException is thrown.

I keep running into the checked versus unchecked debate in my
projects. Here it is again.

How am I supposed to support checked exceptions in my library
when there is no support for the sorts of error raised in the
wrapper APIs? How do I propagate an IOException through a W3C
DOM Node.getFirstChild() ?

 

[Antti S. Brax]

How am I supposed to support checked exceptions in my library
when there is no support for the sorts of error raised in the
wrapper APIs? How do I propagate an IOException through a W3C
DOM Node.getFirstChild() ?

Since you are going to implement a standardized API I think
you're decision is quite easy: you can't provide checked
exceptions.

Your only choice is to convert those exceptions into unchecked
ones. Use initCause. Or maybe you could specify an error handler
for your parser and make your implementation of Node to report
errors to it?

 

[Alan Gutierrez]

Since you are going to implement a standardized API I think
you're decision is quite easy: you can't provide checked
exceptions.

Your only choice is to convert those exceptions into unchecked
ones. Use initCause. Or maybe you could specify an error handler
for your parser and make your implementation of Node to report
errors to it?

Sanity check. Thank you.

I am going to sue uncheck excpetions in my API.

It is just such a point of contention in the Java world, I
wanted to see if my reasoning would be accepted.

I don't want to provide an API like JDBC, with the universal,
and near useless SQLException.

I was trying to develop an exception strategy for observables,
and regardless of how much detail I provided, I couldn't get a
answer beyond, throw checked exceptions, it's the Java way.

The error handler, doesn't make much sense, because I don't
think a node operation will have the context to resolve a
filesystem error. This is a document, not a parser.

Thanks.

 

[Chris Smith]

I'm writing an XML document object model that is paged. It is
not meant to be used directly by application developers, but
through one of the DOM APIs or through an engine like XSLT.

Since it is file based, rather than in memory, there are plenty
of places where IOException is thrown from java.io.*.

Since it is supports concurrent reads, there a are plenty of
places where InterruptedException is thrown.

I keep running into the checked versus unchecked debate in my
projects. Here it is again.

How am I supposed to support checked exceptions in my library
when there is no support for the sorts of error raised in the
wrapper APIs? How do I propagate an IOException through a W3C
DOM Node.getFirstChild() ?

Since you're using DOM, you should create and throw a DOMException,
which extends RuntimeException. The DOMException class uses error codes
from the DOM specification, which are listed in the API docs for that
class. Use the initCause method to attach the original exception to
your DOMException, so that you don't lose the added information for
debugging purposes.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[alan]

Since you're using DOM, you should create and throw a DOMException,
which extends RuntimeException. The DOMException class uses error codes
from the DOM specification, which are listed in the API docs for that
class. Use the initCause method to attach the original exception to
your DOMException, so that you don't lose the added information for
debugging purposes.

I don't know if it makes sense to wrap a concurrency exception
into a DOMException. If you're using a utility that operates on
W3C DOM, if it catches the DOMException, it won't know what to
make of the inner InterruptedException, which inidcates that a
lock aquisution on the database timed out.

Only the application developer is going to know to expect IO and
interrupted exceptions, and their catch ladders would be easier
to write if they could catch an exception typed so as to
indicate that it came from the database.