On 17.04.2004 12:38, Nicola Ken Barozzi wrote:
In any case, what I see is that Cocoon has gotten many contracts wrong.
In particular it has been coded using generic Cocoonish exceptions that
were meant to gobble up the source exceptions from the start. In fact we
can say that what seems now as
Ugo Cei wrote:
Guido Casper wrote:
Ugo Cei wrote:
WebDAVRepository.java (swallowed):
} catch (ProcessingException pe) {
this.getLogger().error(Error saving dom to: + this.repoBaseUrl
+ uri, pe);
}
WebDAVRepositoryPropertyHelper.java (swallowed):
} catch (ProcessingException pe) {
Il giorno 16/apr/04, alle 00:02, Ugo Cei ha scritto:
The change is backward-compatible and is a one-line change that can be
reverted easily, but might have implications on the way we manage
exceptions in the future.
Actually, we have a few cases of catch(CascadingException) here and
there,
Ugo Cei wrote:
I think everyone interested has had the option of venting his opinion on
the subject of checked vs. unchecked exceptions. For the record, here
[1] is the relevant thread.
In order to move forward, I propose to reparent the
org.apache.cocoon.ProcessingException to extend
Nicola Ken Barozzi wrote:
Ugo Cei wrote:
I think everyone interested has had the option of venting his opinion
on the subject of checked vs. unchecked exceptions. For the record,
here [1] is the relevant thread.
In order to move forward, I propose to reparent the
Reinhard Pötz wrote:
Nicola Ken Barozzi wrote:
Ugo Cei wrote:
I think everyone interested has had the option of venting his opinion
on the subject of checked vs. unchecked exceptions. For the record,
here [1] is the relevant thread.
In order to move forward, I propose to reparent the
Ugo Cei wrote:
Nicola Ken Barozzi wrote:
In any case (and note that this is a vote, not a veto) the main reason
is that in doing this we risk to throw out the baby with the water: I
prefer a lot to remove ProcessingExceptions comptely and have the
Cocoon components throw all the exceptions
Reinhard Pötz wrote:
Nicola Ken Barozzi wrote:
Ugo Cei wrote:
I think everyone interested has had the option of venting his opinion
on the subject of checked vs. unchecked exceptions. For the record,
here [1] is the relevant thread.
In order to move forward, I propose to reparent the
Nicola Ken Barozzi wrote:
In any case (and note that this is a vote, not a veto) the main reason
is that in doing this we risk to throw out the baby with the water: I
prefer a lot to remove ProcessingExceptions comptely and have the Cocoon
components throw all the exceptions that the container
Nicola Ken Barozzi wrote:
Ugo Cei wrote:
We have something worse than generic ProcessingExceptions being
thrown, we have components throwing CascadingException. Which not only
force clients to check them, but create an unnecessary dependence on
Avalon.
Whaich I agree with, but still it's not
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
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
Ugo Cei wrote:
Nicola Ken Barozzi wrote:
Ugo Cei wrote:
We have something worse than generic ProcessingExceptions being
thrown, we have components throwing CascadingException. Which not
only force clients to check them, but create an unnecessary
dependence on Avalon.
Whaich I agree with, but
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
Nicola Ken Barozzi wrote:
Ugo Cei wrote:
For 2.2 (which we have agreed will require JDK 1.4 IIRC, so we can
count on exception chaining) I will propose to define a
Cocoon-specific hierarchy of exceptions, whose root is
java.lang.RuntimeException. And 3rd party exception classes like
Marc Portier wrote:
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 :-(
This is fine, in theory. In practice, our codebase is full of
Ugo Cei wrote:
I think everyone interested has had the option of venting his opinion on
the subject of checked vs. unchecked exceptions. For the record, here
[1] is the relevant thread.
In order to move forward, I propose to reparent the
org.apache.cocoon.ProcessingException to extend
Nicola Ken Barozzi wrote:
Ugo Cei wrote:
Nicola Ken Barozzi wrote:
In any case (and note that this is a vote, not a veto) the main
reason is that in doing this we risk to throw out the baby with the
water: I prefer a lot to remove ProcessingExceptions comptely and
have the Cocoon components
Am Fr, den 16.04.2004 schrieb Ugo Cei um 0:02:
In order to move forward, I propose to reparent the
org.apache.cocoon.ProcessingException to extend
org.apache.avalon.framework.CascadingRuntimeException instead of
CascadingException.
So, please cast your votes.
+1
Stephan.
Ugo Cei wrote:
I think everyone interested has had the option of venting his opinion on
the subject of checked vs. unchecked exceptions. For the record, here
[1] is the relevant thread.
In order to move forward, I propose to reparent the
org.apache.cocoon.ProcessingException to extend
I'm not a committer, but +1 from me.
The ProcessingException isn't supposed to be caught by the immediate
client, but propagated all the way up the stack. It therefore seems
unneccessary to burden the intermediate layers with having to declare
throws ProcessingException.
/LS
From: Unico
Ugo Cei u.cei at cbim.it writes:
catch (ProcessingException e) {
getLogger().*(*);
throw new *Exception(*, e);
}
I'm not very experienced with designing Java class models and even less with
checked vs. unchecked exceptions. But the proposal cries IMHO for unforeseen
effects
Ugo Cei wrote:
Nicola Ken Barozzi wrote:
Ugo Cei wrote:
For 2.2 (which we have agreed will require JDK 1.4 IIRC, so we can
count on exception chaining) I will propose to define a
Cocoon-specific hierarchy of exceptions, whose root is
java.lang.RuntimeException. And 3rd party exception
I am a little confused, it seemed like the direction of the discussion
on checked vs. unchecked exceptions was leading us down the path of this
vote. I realize that there are valid points on both sides of the issue,
so for my benefit and the benefit of everyone, I am going to try and
restate
Le 16 avr. 04, à 15:28, Marc Portier a écrit :
...I'm not currently not convinced there could be anything else then
careful consideration on each point in the code, sorry if this is bad
news
I tend to agree.
I don't have time currently to seriously follow the discussion, but a
quick random
Geoff Howard wrote:
If the end-result of this is users seeing
more stacktraces, or plain 404 or 500 errors, I go -1.
Users should see *shorter* and more meaningful stacktraces.
If the end
result is developers can still catch errors in the sitemap and display
custom oops pages instead (as
Joerg Heinicke wrote:
Ugo Cei u.cei at cbim.it writes:
catch (ProcessingException e) {
getLogger().*(*);
throw new *Exception(*, e);
}
I'm not very experienced with designing Java class models and even less with
checked vs. unchecked exceptions. But the proposal cries IMHO for
Ugo Cei wrote:
...
And for the specific case of ProcessingExceptions: Does not almost
every of our
components have the ProcessingException in its throws clause? So where
is the
need for catching/wrapping/rethrowing them?? Only current bad usage is
not a reason for changing it IMO.
The compiler
Ugo Cei u.cei at cbim.it writes:
But the proposal cries IMHO for unforeseen
effects like not caught exceptions where they should have been caught.
If all you do is log (maybe) and rethrow, this is a clear indication of
the fact that the exception should NOT have been caught in the first
Ugo Cei wrote:
Nicola Ken Barozzi wrote:
Ugo Cei wrote:
For 2.2 (which we have agreed will require JDK 1.4 IIRC, so we can
count on exception chaining) I will propose to define a
Cocoon-specific hierarchy of exceptions, whose root is
java.lang.RuntimeException. And 3rd party exception
Joerg Heinicke wrote:
The compiler forces you to catch them.
Of course, but only exactly once at the end. How are the exceptions made
available to handle-errors at the moment? I guess somewhere in the tree
processor. So where is the problem letting it catch the exception? I still don't
see the
Nicola Ken Barozzi wrote:
You are forced by a contract, just as you are forced by other types.
Personally, I don't buy this design by contract thing, I much prefer
design by testing, or Test Driven Design, if you prefer :-).
He should blame the fact that he does not have ProcessingException in
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?
AbstractCommandLineEnvironment.java:
} catch (ProcessingException pe) {
throw new CascadingIOException(ProcessingException: + pe, pe);
}
Ugo Cei wrote:
WebDAVRepository.java (swallowed):
} catch (ProcessingException pe) {
this.getLogger().error(Error saving dom to: + this.repoBaseUrl +
uri, pe);
}
WebDAVRepositoryPropertyHelper.java (swallowed):
} catch (ProcessingException pe) {
this.getLogger().error(Error
Guido Casper wrote:
Ugo Cei wrote:
WebDAVRepository.java (swallowed):
} catch (ProcessingException pe) {
this.getLogger().error(Error saving dom to: + this.repoBaseUrl
+ uri, pe);
}
WebDAVRepositoryPropertyHelper.java (swallowed):
} catch (ProcessingException pe) {
On 16.04.2004 16:47, Ugo Cei wrote:
The compiler forces you to catch them.
Of course, but only exactly once at the end. How are the exceptions made
available to handle-errors at the moment? I guess somewhere in the tree
processor. So where is the problem letting it catch the exception? I
still
Joerg Heinicke wrote:
On 16.04.2004 16:47, Ugo Cei wrote:
The conventional wisdom is that it's better to have the compiler
remind you that you have to catch most exceptions, because that's part
of the contract. My opinion, instead, is that checked exceptions are a
very bad way of enforcing
I think everyone interested has had the option of venting his opinion
on the subject of checked vs. unchecked exceptions. For the record,
here [1] is the relevant thread.
In order to move forward, I propose to reparent the
org.apache.cocoon.ProcessingException to extend
Le 16 avr. 04, à 00:02, Ugo Cei a écrit :
...In order to move forward, I propose to reparent the
org.apache.cocoon.ProcessingException to extend
org.apache.avalon.framework.CascadingRuntimeException instead of
CascadingException
+1
-Bertrand
39 matches
Mail list logo
