commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andre Dantas Rocha" <andre.dantas.ro...@uol.com.br>
Subject RES: RES: Possible incubation?
Date Wed, 08 Apr 2009 18:49:24 GMT
Hi Jorg,

Thank you again for your comments. I believe you are partially right, let me explain...

Using Jeha it is possible to specify blocks where you'd like to use handle() method. Other
blocks always can have different strategies, for example:

try {
  doSomethingRisky();
}
catch (NamingException e) {
  // my handling code, continue, etc.
} 
catch(Exception e){
  // let Jeha do the job
  HandleUtil.handle(e);
}

The point is that, if you do not specify HandleUtil.handle() location and use Ant task, the
framework will inject a call to HandleUtil.handle() in each catch block. If no catch is found,
the whole method will be involved with a try/catch.

When one decides to use an "catch all" approach (or Ant task), it seems to me that any exception
must be treated the same way.

You and Gaurav are talking about an point that really needs some kind of improvement: how
can I restrict handler scope and specify which exceptions must be handled at all without code
HandleUtil.handle()?

Well, I don't know yet. Suggestions are welcome :-)

Andre



-----Mensagem original-----
De: news [mailto:news@ger.gmane.org] Em nome de Jörg Schaible
Enviada em: quarta-feira, 8 de abril de 2009 12:11
Para: dev@commons.apache.org
Assunto: Re: RES: Possible incubation?

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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message