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 10:43:55 GMT


Ugo Cei wrote:

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

oh, did I say they should stop?

I agree that the recovery component that would try to re-ensure XML 
welformdness is highly hypothetical to the level of plain useless

but in more general terms: recovering from malformed sax stream could be 
really easy: I'm reading in a configuration file through sax, if that is 
bogus I switch to defaults... (I surely don't need to break completely, 
and I'm quite glad the system reminded me of the fact that when dealing 
with XML this issue is not to be totally overlooked)

> 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 who are we to measure this awkwardness in our project in relation to 
all other uses of SAX out there?

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

which fails to indicate that most likely the XML processing should be 
stopped

I agree to do it like this if the above most likely does not stand, in 
all other cases this will ensure a higher coupling up the call stack:

since someone up there will need to (and out of the blue) couple the 
occurance of a DataAccessException to notyfing the SAX aware components

> 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.
>    }
> 

agree, but higher up the chain is someone that doesn't know there are 
databases involved, and doesn't want to: the only thing he knows is 
SAXevents (and SAXexceptions) (he's not going to elegantly handle 
database related things)

so why would that class ever provide this catch?

and if he catches RuntimeException instead, then what is the semantical 
meaning of that?

and if he doesn't: how to just continue with the default config?

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

hehe, me too, but I still fail to attach the label 'unnecessary'

specially if the price we pay is the introduction of higher-surprise 
occurance of other code (i.e. when the DataAccessException occurs in a 
spot that doesn't know about databases, but needs this clause to signal 
the XML aware components so they can safely recover...)

What I'm buying here is clarity at the price of verbosity. A good deal 
over reduced kLOCs at the price of obscurity...
IMHO: there are tools that help out with verbosity, for obscurity you're 
on your own :-(

-marc= (doubthing there is an easy answer to this)
-- 
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