2012-11-13 6 views
2

Je travaille sur un code côté serveur qui enveloppe toutes les exceptions avant de les passer du côté client, en raison de tout cela des méthodes avec les clients ont le code suivantSEC pour Exception Emballage

try{ 
    DoSomething(); 
} catch (ExceptionA e) { 
    throw new CustomException(AType, e); 
} catch (ExceptionB e) { 
    throw new CustomException(BType, e); 
} catch (Exception e) { 
    throw new CustomException(Unexpected, e); 
} 

d'avoir cette répété dans chaque méthode semble violer le principe DRY et je me demandais quelle serait la meilleure façon de le refactoriser. Par exemple, je pensais une méthode d'emballage tels que:

private void wrapException(Exception e) { 
if (e instanceof ExceptionA) { 
    throw new CustomException(AType, e); 
} 
etc... 

Répondre

2

Jetez un oeil à AspectJ adoucir exception.

Regardez également les Throwables de Guava.

Il existe également une exception sournoise de Lamboks.

L'autre option consiste à utiliser des instances d'objets anonymes, nommées fermetures.

public abstract class Wrapper { 
    public void execute() { 
     try { 
      // do some boiler plate before 
      this.wrap(); 
      // do some boiler plate after. 
     } catch (ExceptionA | ExceptionB ex) { 
      Type t = determineType(ex); 
      throw new CustomException(t, ex); 
     } 
    } 
    public void abstract wrap(); 
} 

maintenant dans votre code que vous faites quelque chose comme:

new Wrapper() { 
    public void wrap() { 
     DoSomething(); 
    } 
}.execute() 
+0

Bibliothèques intéressantes mais elles ne s'appliquent pas vraiment à mon problème. Je cherche à refactoriser une erreur standard, de préférence sans les bibliothèques externes. – FooBar

+0

Oui, mais vous pouvez regarder comment fonctionne Throwables.propagate (code sage) –

0

C'est une façon d'aller à ce sujet:

Exception caughtEx = null; 
String extraInfo = null; 
try{ 
    DoSomething(); 
} catch (ExceptionA e) { 
    caughtEx = e; 
    extraInfo = AType; 
} catch (ExceptionB e) { 
    caughtEx = e; 
    extraInfo = BType; 
} catch (Exception e) { // catching Exception is usually a bad idea, just let it bubble up without catching... 
    caughtEx = e; 
    extraInfo = Unexpected; 
} 
if (caughtEx != null) throw new CustomException(extraInfo, caughtEx); 
+0

Cela finirait par être plus de code et moins modulaire qu'il ne l'est actuellement. L'interception et l'encapsulation des exceptions sont importantes pour ne pas exposer l'implémentation côté serveur au client. – FooBar

+0

@FooBar Dans cet exemple simple, c'est plus de code, mais si le bloc "then" à la fin est plus long, ou s'il contient du code non-standard, vous ne voulez pas le répéter, alors cela commence à avoir du sens. – hyde

+0

Vous avez mal compris la question que je pense. Les prises d'essai ne sont pas dans une seule méthode, elles sont dans des méthodes publiques face au client. Cela nécessiterait toujours que la méthode standard soit dans toutes les méthodes. – FooBar