cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [VOTE] Make ProcessingException extend CascadingRuntimeException
Date Fri, 16 Apr 2004 09:00:15 GMT


Ugo Cei wrote:


> How about this?
> 
>   } catch (ProcessingException e) {
>     getLogger().debug("Rethrowing exception", e);
>     throw new SAXException(e);
>   }
> 
> This is not only useless, it's plain wrong.
> 

why so?

because SAXExceptions must be related to XML and it might be that this 
ProcessingException was related to e.g. sql operations?  And this breaks 
with the 'IS A' test?

I'm not sure: I think this depends on your understanding of what is the 
meaning of a SAXException.  Its purpose of existence is not to 
communicate XML related errors, its purpose is to communicate to XML 
processing components that they should stop doing so since 
wellformedness of the communicated data (somewhere along the pipe) is 
not ensured?


would this be your alternative then:
have a SAXWrappingProcessingException subclass that can only wrap a 
SAXException that should be plainly unwrapped and rethrown in the case 
that the context allows for it?

    } catch (SAXWrappingProcessingException e) {
      throw e.getWrappedSAXException();
    }
    // not catching the ProsessingException will just let it propagate


-marc= (still enthousiastically trying to be enthousiast)
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org

Mime
View raw message