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:
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?
Thanks for taking the time to do it. Now, let's try to analyze and see
what is the real use of them.
AbstractCommandLineEnvironment.java:
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) {
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 con
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 do
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) {
this.getLog
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 se
Ugo Cei wrote:
a more serious issue. You cannot go by the type of exception alone.
By allowing the ProcessingException to have this additional
information embedded, the Sitemap can better handle creating more
accurate error pages.
I'm confused here. Doesn't it already have it embedded?
only
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);
}
HTMLTra
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
Ugo Cei wrote:
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.
No, that was my point. Developers should see shorter more meaningful
stacktraces. Users should neve
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 need
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 classes
Ugo Cei 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 p
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 f
Berin Loritsch wrote:
The core problem that the proposed vote was trying to solve was to
remove the need to catch a ProcessingException if we are merely going to
log and rethrow it.
Yes.
Does the ProcessingException allow you to store any clues as to the type
of error handling we need (i.e. HTT
Joerg Heinicke wrote:
Ugo Cei 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
e
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
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
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 t
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 class
Ugo Cei 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 like
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 Hom
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
org.apa
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.
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 t
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
org.apa
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 rethrow
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
SAXExceptio
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
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 s
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:
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
ProcessingExcept
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 abo
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 tha
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
org.a
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 c
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
org.apa
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
org.apache.cocoon.ProcessingE
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
org.apac
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, th
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
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
org.apache.avalon.frame
43 matches
Mail list logo
