Attraper des exceptions non gérées dans le contrôle Web pour permettre la page de rendre

Question

(J'utilise en fait Ektron CMS, et j'utilise Widgets, qui sont une extension très simple d'un contrôle utilisateur).

Problème: J'ai une page Web qui contient de nombreux widgets. Si une exception se produit dans l'un de ces widgets, la page s'arrête et l'utilisateur reçoit une erreur de serveur. Je voudrais avoir des exceptions non gérées dans un widget pour enregistrer l'exception, arrêter l'affichage de ce widget et permettre à la page de continuer.

E.g. Vous avez un widget météo sur chaque page qui obtient des données via un service Web. Si le service Web vous envoie du code XML malformé, vous souhaitez que le site soit toujours disponible.

solutions possibles:
Plan A) Dans chaque widget enveloppent le contenu de la fonction d'initialisation ou d'affichage dans une instruction try-catch.
Plan B) Créez une nouvelle interface IRobustWidget qui étend IWidget et exécute Try-Catch.

Ces deux options me semblent un peu «sales», car j'ai lu que les instructions génériques catch (exception) sont un peu anti-pattern. Je me penche vers le plan B, car cela semble plus modulaire.

• Est-ce que j'ai manqué d'autres options?
• Est-ce qu'un Try-Catch générique est ok à cet égard?

(I've also logged this at the Ektron forums)

Answer 1

Le fait que vous chargez les données via un service Web me demande si vous devriez peut-être charger cette async de données, soit par un ajax chargé <div>, ou un ; c'est-à-dire que le (s) widget (s) est (sont) téléchargé (s) dans des demandes séparées. Cela vous obtient deux avantages:

• la page principale ne soit pas retardée du tout en obtenant les données - qui doivent charger brièvement après la page principale ne
• si le panneau ne se charge pas .... meh (en supposant qu'il est agréable d'avoir mais non critique)

L'inconvénient est un aller-retour supplémentaire, mais par rapport à tout ce qui se passe, cela ne pose pas nécessairement de problème.

Answer 2

J'ai trouvé ce que je après- Catching unhandled exceptions in ASP.NET UserControls

Je me rends compte aussi que je dois décider quel événement que je dois me concentrer sur (Render, charge ou une fonction SetDisplay personnalisée)