Les gestionnaires d'événements asynchronisés devraient-ils être évités?

Gestionnaire d'événements asynchrones : gérer la méthode vide asynchrone

Dans le domaine de la programmation asynchrone, la pratique consistant à utiliser des méthodes vides asynchrones "démarrer et oublier" pour démarrer des tâches est souvent déconseillée car cette méthode manque de traçabilité des tâches suspendues et est difficile à gérer, ce qui peut survenir dans de telles méthodes. Cependant, avec les gestionnaires d’événements asynchrones, la question se pose : faut-il appliquer le même principe d’évitement ?

Raisons des gestionnaires d'événements asynchrones

Sans aucun doute, l’approche recommandée est d’éviter d’utiliser des méthodes asynchrones nulles. Toutefois, les gestionnaires d’événements nuls asynchrones constituent une exception. En effet, les gestionnaires d'événements ont un contexte asynchrone naturel et sont généralement utilisés pour une exécution spécifique et unique, de sorte que les valeurs de retour manquantes posent moins de problèmes.

Exemple : Revisiter le scénario de chargement du formulaire

Considérez le gestionnaire d'événements nuls asynchrone suivant :

<code>private async void Form_Load(object sender, System.EventArgs e)
{
        await Task.Delay(2000); // 执行异步操作
        // ...
} </code>

Pour atténuer les défauts potentiels, nous pouvons le refactoriser comme suit :

<code>Task onFormLoadTask = null; // 跟踪任务，可以实现取消

private void Form_Load(object sender, System.EventArgs e)
{
        this.onFormLoadTask = OnFormLoadTaskAsync(sender, e);
} 

private async Task OnFormLoadTaskAsync(object sender, System.EventArgs e)
{
        await Task.Delay(2000); // 执行异步操作
        // ...
} </code>

Bien que cette approche offre un meilleur contrôle sur la tâche et permette l'annulation, elle ajoute du code passe-partout supplémentaire.

Risques cachés dont il faut être conscient

En plus des problèmes potentiels de réentrance, il existe des risques plus subtils avec les gestionnaires d'événements asynchrones :

• Thread Safety : Les gestionnaires d'événements asynchrones sont essentiellement appelés sur le thread de l'interface utilisateur. Si les opérations asynchrones associées nécessitent des threads de longue durée, cela peut entraîner une interface utilisateur qui ne répond pas.
• Gestion des exceptions : Les exceptions qui se produisent dans les gestionnaires d'événements asynchrones peuvent être difficiles à gérer car elles peuvent éventuellement remonter jusqu'au mécanisme d'exception non géré.

Conclusion

Bien que les gestionnaires d'événements nuls asynchrones soient généralement acceptables, il est important d'être conscient de leur impact potentiel. En étant prudent et en éliminant la logique d'un gestionnaire d'événements nuls asynchrone pour les tests unitaires, vous pouvez profiter de la puissance de la programmation asynchrone sans compromettre la qualité ou la maintenabilité du code.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!