Hi Andre,
Andre Dantas Rocha wrote at Mittwoch, 8. April 2009 15:17:
> Hi Jorg,
>
> I understand your point, and maybe the framework need some improvement.
> Today it's only an initial code (any help and ideas are welcome).
>
> In my opinion handleException() must handle the original exception and all
> exceptions that occurs inside it, so the code ever stops in this method:
>
> // code in framework
> public Throwable handleException(Throwable t) {
> try {
> ...
> }
> catch (Exception e) {
> // appropriate handling here
> }
> finally {
> return t;
> }
> }
>
> // usage
> try {
> doSomethingRisky();
> catch(Exception e){
> handleException(e);
> }
>
> If you want to propagate the original exception, you can do this:
>
> try {
> doSomethingRisky();
> catch(Exception e){
> throw handleException(e);
> }
and this is the problem, how do I embed this in any method? See:
void foo() throw Throwable // Uuhhha :-/
{
try {
doSomethingRisky();
catch(Exception e){
throw handleException(e);
}
}
And if I want to throw something specific:
void foo() throw NamingException
{
try {
doSomethingWithJNDI();
catch(Exception e){
throw (NamingException)handleException(e);
}
}
I make strange assumptions about my handler. Additionally a handler is
limiting, you might have more exit strategies:
int foo()
{
try {
doSomething();
catch(Exception e){
return -1; // how can I handle this ?
}
}
int foo()
{
foreach(Object o: list)
try {
doSomethingWith(o);
catch(Exception e){
continue; // or this ?
}
}
> Maybe we can add a new parameter in handleException() specifying if the
> inside exception must be propagated. What do you think? Any new idea is
> valuable to solve the problem, if you have one please share...
>
> And... thanks for showing this kind of problem.
Don't get me wrong. I simply cannot think of a generalized handler
implementation that covers the limits of Java and that allows be an
equivalent to:
int foo() throws NoSuchElementException
{
try {
doSomething();
catch(NamingException e, IllegalArgumentException e){
// do the same for all catched, but do not handle NSEE or other RE's
}
}
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
