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 16:03:43 GMT
Nicola Ken Barozzi wrote:
> Since you know that we have dozens of places in the code with this 
> thing, do you care posting a dozen of them here?

   } catch (ProcessingException pe) {
     throw new CascadingIOException("ProcessingException: " + pe, pe);
   } (this is wicked!):

   } catch (ProcessingException e) {
   } (does it twice):

   } catch (ProcessingException e) {
     throw new SAXException(e);
   } catch (IOException e) { (at least we rethrow a runtime exception here):

   } catch (ProcessingException pe) {
     throw new CascadingRuntimeException("Unable to create simple 
context.", pe);

   } catch (ProcessingException se) {
     throw new ConfigurationException("Exception during configuration of 
handler: " + name, se);
   } (might be legit here, but if it is, should 
use "warn", shouldn't it?):

   } catch (ProcessingException local) {
     this.getLogger().error("authenticator: " + local.getMessage(), local);
     exceptionMsg = local.getMessage();

   } catch (ProcessingException pe) {
     throw new SAXException("ProcessingException", pe);
   } (does it twice):

   } catch (ProcessingException pe) {
     throw new SAXException(pe);
   } (does it three times):

   catch(ProcessingException e) {
     throw new CascadingIOException("Failure storing response.", e);

   } catch (ProcessingException se) {
     throw new ParameterException("Unable to read configuration from " + 
configurationFile, se);
   } catch (SAXException se) { (swallowed twice):

   catch (ProcessingException ex) {
     getLogger().error("Could not create new coplet instance", ex);
   catch (ProcessingException pe) {
       "Error while getting portal application configuration for coplet "
         + coplet.getId(),

   } catch (ProcessingException pe) {
     throw new CascadingRuntimeException("Exception during removal.", pe);
   } (swallowed three times, logged once):

   } catch (ProcessingException pe) {
     this.getLogger().warn("Unable to create new instance.", pe);
   } catch (ServiceException se) {

   } catch (ProcessingException e) {
     throw new SAXException("Unable to fetch the query data:", e);
   } (swallowed):

   } catch (ProcessingException pe) {
     this.getLogger().error("Error saving dom to: " + this.repoBaseUrl + 
uri, pe);
   } (swallowed):

   } catch (ProcessingException pe) {
     this.getLogger().error("Error serializing node " + value, pe);

That's 23, then I stopped pasting. But considering all the catch clauses 
for ProcessingException and its subclasses we have:

ProcessingException: 64 occurences
ConnectionResetException: 4 occurences
ResourceNotFoundException: 10 occurrences

But ProcessingException is just one example. Avalon's CascadingException 
  has 14 children exception classes. For instance, 
org.apache.avalon.framework.configuration.ConfigurationException, which 
is heavily used by CForms for doing things like:

   throw new ConfigurationException("Convertor defined in plain 
attribute unavailable.", e);

Now, don't tell me that distributing an incorrect configuration file is 
not a programming error. Do contracts also cover the case of programming 
errors? I suspect this should be a runtime exception. Better yet, when 
we have Java 1.4 as a requirement, this should be:

	assert false, "Convertor defined in plain attribute unavailable.";


View raw message