cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ugo Cei <>
Subject Re: [VOTE] Make ProcessingException extend CascadingRuntimeException
Date Fri, 16 Apr 2004 09:36:19 GMT
Marc Portier wrote:
> 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?

I might agree with this. But if I were to agree completely, I would make 
SAXException unchecked, since, if XML processing components should stop 
processing, they might as well be interrupted by a runtime exception. 
How are they expected to recover from a malformed SAX stream?

Well, in some cases you could, if you *really* must, but in practice 
very few components would need to. But now they are forced to deal with 
it by logging, wrapping and rethrowing.

But suppose we aren't given the luxury of catching a ProcessingException 
that we can ignore if we make it unchecked. Suppose we have to catch an 
SQLException, which we cannot change. Then, that's what I would do (if I 
  were to agree with your reasoning above):

   catch (SQLException sqle) {
     throw new org.apache.cocoon.RuntimeSAXException
         ("While doing this and that:", sqle);

But since I'm not sure I completely agree with that reasoning, more 
probably I would do:

   catch (SQLException sqle) {
     throw new org.apache.cocoon.DataAccessException
         ("While doing this and that:", sqle);

The DataAccessException (unchecked) would have enough knowledge of 
SQLException to extract meaningful information from it, like SQL error 
codes and maybe even proprietary error codes (think Oracle, for 
instance). It would also have knowledge of other methods for accessing 
databases: JDO, Hibernate, etc. Thus, if you wanted to deal with data 
access exceptions in a persistence-layer-independent way, you could do:

    catch (DataAccessException dae) {
        // Extract enough information, if available, and see if we
        // can recover or not.

> 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)

My alternative in this particulare instance is just to delete the three 
lines of code above. Aren't you enthusiastic about the prospect of 
removing unnecessary code? I usually am ;-).


View raw message