Propigating Exceptions Through APIs

Discussion in 'Java' started by Alan Gutierrez, Feb 7, 2005.

  1. 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() ?

    --
    Alan Gutierrez -
     
    Alan Gutierrez, Feb 7, 2005
    #1
    1. Advertising

  2. wrote in comp.lang.java.programmer:
    > 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?

    --
    Antti S. Brax Rullalautailu pitää lapset poissa ladulta
    http://www.iki.fi/asb/ http://www.cs.helsinki.fi/u/abrax/hlb/
    "Disconnect this cable to shorten, re-connect to lengthen."
    -- Instructions on Logitech's USB mouse extension cord.
     
    Antti S. Brax, Feb 7, 2005
    #2
    1. Advertising

  3. On 2005-02-07, Antti S. Brax <> wrote:
    > wrote in comp.lang.java.programmer:
    >> 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?


    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.

    --
    Alan Gutierrez -
     
    Alan Gutierrez, Feb 7, 2005
    #3
  4. Alan Gutierrez

    Chris Smith Guest

    Alan Gutierrez <> wrote:
    > 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
     
    Chris Smith, Feb 7, 2005
    #4
  5. Alan Gutierrez

    Guest

    On 2005-02-07, Chris Smith <> wrote:
    > Alan Gutierrez <> wrote:
    >> 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.


    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.

    --
    Alan Gutierrez -
     
    , Feb 7, 2005
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?TGVubnk=?=

    Win32 APIs in ASP.NET application

    =?Utf-8?B?TGVubnk=?=, Jan 16, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    307
    Kevin Spencer
    Jan 16, 2004
  2. Ahmed Moustafa
    Replies:
    5
    Views:
    30,042
    Chris Smith
    Jul 14, 2004
  3. Paul Miller
    Replies:
    3
    Views:
    1,024
    Alex Martelli
    Nov 12, 2003
  4. Replies:
    3
    Views:
    615
    Sherm Pendley
    Apr 16, 2007
  5. Lie
    Replies:
    3
    Views:
    636
Loading...

Share This Page