Si le lancer System.Exception
est considéré comme si mauvais, pourquoi n'a-t-il pas été Exception
fait abstract
en premier lieu?
De cette façon, il ne serait pas possible d'appeler:
throw new Exception("Error occurred.");
Cela imposerait l'utilisation d'exceptions dérivées pour fournir plus de détails sur l'erreur qui s'est produite.
Par exemple, lorsque je veux fournir une hiérarchie d'exceptions personnalisée pour une bibliothèque, je déclare généralement une classe de base abstraite pour mes exceptions:
public abstract class CustomExceptionBase : Exception
{
/* some stuff here */
}
Et puis une exception dérivée avec un objectif plus spécifique:
public class DerivedCustomException : CustomExceptionBase
{
/* some more specific stuff here */
}
Ensuite, lors de l'appel d'une méthode de bibliothèque, on pourrait avoir ce bloc try / catch générique pour intercepter directement toute erreur provenant de la bibliothèque:
try
{
/* library calls here */
}
catch (CustomExceptionBase ex)
{
/* exception handling */
}
Est-ce une bonne pratique?
Serait-ce bien si Exception
c'était rendu abstrait?
EDIT: Mon point ici est que même si une classe d'exception est marquée abstract
, vous pouvez toujours l'attraper dans un bloc fourre-tout. Le rendre abstrait n'est qu'un moyen d'interdire aux programmeurs de lever une exception "super large". Habituellement, lorsque vous lâchez volontairement une exception, vous devez savoir de quel type il s'agit et pourquoi cela s'est produit. En imposant ainsi de lever un type d'exception plus spécifique.