6
votes

Dresser une exception de l'événement AppDomain.assemLyload

Quelqu'un peut-il m'expliquer pourquoi je ne peux pas sembler jeter une exception à l'intérieur de l'événement AppDomain. Par exemple: xxx

Lorsque j'exécute cela, la sortie est la suivante: xxx

peut-on expliquer ce comportement? Merci.

Modifier pour clarifier quelques objets:

  • L'événement de chargement de l'assemblage fonctionne bien, lorsque je m'attends à ce qu'elle fonctionne. Mais mon exception n'est jamais lancée

  • Il s'agit d'un exemple distillé tiré d'une application plus grande. Je veux inspecter l'assemblée après qu'il est chargé et si je n'aime pas quelque chose à ce sujet, je veux échouer vite ... mais mon exception n'arrive pas "arriver"


3 commentaires

Exécutez-vous sur une machine 64 bits? J'ai eu un problème très similaire. Voir: Stackoverflow.com/questions/4125876/...


@Cpfohl: merci, je suis sur x64 mais ma citation de la plate-forme est déjà x86 ...


En fait, cela a du sens de toute façon, puisque l'erreur est destinée au chargement des formulaires, sans chargement général.


4 Réponses :


2
votes

Cela se produit à cause de la façon dont le compilateur JIT fonctionne. Il doit générer le code de la méthode principale () avant de pouvoir commencer à exécuter. Puisque vous référencez le type de ClassLibrary1.class1 (), il doit charger cet ensemble pour récupérer les informations de type. Cela nécessite qu'il charge l'assemblage avant em> votre code commence à exécuter. Changez-le comme ceci pour obtenir l'exception:

using System.Runtime.CompilerServices;
...
    static void Main(string[] args) {
        Test();
    }
    [MethodImpl(MethodImplOptions.NoInlining)]
    static void Test() {
        Console.WriteLine(new ClassLibrary1.Class1().TestString());
        Console.WriteLine();
        Console.WriteLine("Done...");
        Console.ReadLine();
    }


1 commentaires

Merci mais cela ne semble pas fonctionner ... Le résultat est le même.



0
votes

Je pense que l'événement de chargement de l'assemblage se produit sur un thread séparé, en utilisant ASYNCCallback. Vous n'obtenez pas l'exception parce que vous devez utiliser Application.threadException + = nouveau System.threading.threadexceptionventhandler (application_threadexception);

Je pense que je ne suis pas un expert à ce sujet du tout


0 commentaires

1
votes

L'exception est lancée. Mais il semble que .NET ignore parfois les exceptions qui se produisent dans le démarrage (principale ()). Je ne suis pas sûr de la raison, mais je vais habituellement à déboguer-> Exceptions et vérifiez la case "Jeton" pour les exceptions courantes de la langue d'exécution "pour pouvoir rompre à l'exception.


1 commentaires

Oui tu as raison. L'exception est lancée en supposant que j'ai permis à VS de briser des exceptions levées ... mais l'exécution continue de toute façon.



1
votes

Pourquoi pensez-vous que l'exception n'est pas lancée? S'il n'y avait pas été lancé, on s'attendait à voir que votre "ne devrait jamais arriver ici ..." Sortie. Cependant, puisque ce n'est pas là, l'exception est probablement lancée.

Votre code n'est pas attraper l'exception est une toute autre histoire. Il est tout à fait possible que le code qui augmente l'événement AppDomain.assemLyload entraîne des exceptions.


3 commentaires

Oui, vous avez raison: bien sûr, mon exception a été lancée (sur la base de la deuxième console.writine non exécutée). Il semble que quelqu'un plus haut augmente est la manipulation de l'exception.


Alors la prochaine question logique est alors pourquoi est-il attrapé? Microsoft a une très forte position sur la garantie d'exceptions propagez toujours dans leurs BCLS s'il est non géré.


@Tyson: L'exception semble être mangée par le CLR, pas la BCL. Quant à la raison pour laquelle il est attrapé, je ne suis pas au courant de toute documentation qui répond à cette question de quelque manière que ce soit.