2010-11-29 14 views
5

Je dois redéclencher une exception qui a été interceptée et stockée ailleurs sans perdre les informations de trace de la pile sur le moment où l'exception a été capturée/stockée. Mon code ressemble à ceci:Préservation de la trace de la pile lors de la réitération des exceptions dans Silverlight

public void Test() 
    { 
     int someParameter = 12; 
     ExecuteSomeAsyncMethod(someParameter, CallbackMethod); 
    } 

    public void CallbackMethod(object result, Exception error) 
    { 
     //Check for exceptions that were previously caught and passed to us 
     if(error != null) 
      //Throwing like this will lose the stack trace already in Exception 
      //We'd like to be able to rethrow it without overwriting the stack trace 
      throw error; 

     //Success case: Process 'result'...etc... 
    } 

J'ai vu des solutions à ce problème qui utilisent la réflexion (par exemple here et here) ou utiliser sérialisation (par exemple here), mais aucun de ceux ne fonctionnera pour moi dans Silverlight (la réflexion privée n'est pas autorisée et les classes/méthodes utilisées dans l'approche de sérialisation n'existent pas dans Silverlight).

Est-il possible de préserver la trace de pile qui fonctionne dans Silverlight?

Répondre

3

Throw une nouvelle exception à l'exception comme exception interne:

throw new ApplcationException("Error message", error); 

L'exception INNER garder trace est pile.

+0

Cela ressemble à ma seule option pour le moment. Malheureusement, cela pourrait/va interférer avec le code existant comme "catch (SpecificExceptionClass)" ou qui autrement vérifie le type de l'exception sur la route. Idéalement, j'aimerais éviter d'exclure l'exception si cela est possible parce que je ne veux pas que les consommateurs commencent à vérifier InnerExceptions pour l'exception «réelle». –

3

Vous pouvez utiliser

catch(Exeption) 
{ 
    throw; 
} 

ou

catch(Exception e) 
{ 
    throw new Exception(e); 
} 

deux gardera la trace de la pile. La première solution ne semble pas possible dans votre exemple, mais la seconde devrait fonctionner.

De cause dans votre cas vous lanceriez le paramètre error au lieu de e.

+0

Si vous voulez mentionner toutes les solutions possibles qui ne fonctionnent pas ici, vous avez oublié la solution la plus simple: ne pas attraper l'exception du tout. ;) – Guffa

+0

@Guffa, vrai ... mais alors il ne sera pas capable de faire la moindre logique qu'il semble vouloir faire quand l'exception se produit. La seule raison pour laquelle j'ai mentionné les deux, c'est qu'une simple réécriture de son code pourrait rendre le premier plus attrayant. Mais vous avez raison, ne pas attraper l'exception, l'empêcherait d'être pris :). –