Vous devez documenter chaque exception qui pourrait être levée par votre code, y compris celles de toutes les méthodes que vous pourriez appeler.
Si la liste devient un peu grande, vous pouvez créer votre propre type d'exception. Attrapez tous ceux que vous pourriez rencontrer dans votre méthode, enveloppez-les dans votre exception et lancez-les.
Un autre endroit où vous voudrez peut-être le faire de cette façon est si votre méthode est sur le visage de votre API. Tout comme une façade simplifie plusieurs interfaces en une seule interface, votre API doit simplifier plusieurs exceptions en une seule exception. Facilite l'utilisation de votre code pour les appelants.
Pour répondre à certaines des préoccupations d'Andrew (à partir des commentaires), il existe trois types d'exceptions: celles que vous ne connaissez pas, celles que vous connaissez et dont vous ne pouvez rien faire, et celles que vous connaissez et pour lesquelles vous pouvez faire quelque chose.
Ceux que vous ne connaissez pas veulent lâcher prise. C'est le principe de l'échec rapide - mieux votre application se bloque que d'entrer dans un état où vous pourriez finir par corrompre vos données. Le crash vous dira ce qui s'est passé et pourquoi, ce qui peut aider à déplacer cette exception de la liste "celles que vous ne connaissez pas".
Ceux que vous connaissez et pour lesquels vous ne pouvez rien faire sont des exceptions comme OutOfMemoryExceptions. Dans des cas extrêmes, vous voudrez peut-être gérer des exceptions comme celle-ci, mais à moins que vous n'ayez des exigences assez remarquables, vous les traitez comme la première catégorie - laissez-les partir. Avez - vous avez à documenter ces exceptions? Vous auriez l'air assez stupide de documenter les MOO sur chaque méthode qui crée un objet.
Ceux que vous connaissez et pour lesquels vous pouvez faire quelque chose sont ceux que vous devriez documenter et emballer.
Vous pouvez trouver plus de directives sur la gestion des exceptions ici.