On est d'accord mais je peux très bien mettre cette information dans mon exception custom. Par exemple en chainant l'exception. Je peux aussi mettre ça dans les logs, ça fait partie du traitement local.
L'appelant (au sens de la méthode) se fous de savoir que le problème est une interruption de flux, un connection reset by peer, ou autre. L'information dont il a besoin c'est "le document n'est pas accessible". Eventuellement si on est sur un outil technique, "le document n'est pas accessible: http 503".
Quand je dis que l'appelant se fous de savoir que c'est une IOException j'entends pas là qu'il est inutile de la remonter. Aujourd'hui c'est une IOException parce que j'utilise les apis type URL / openConnection, demain ce sera une StreamException parce que j'aurais switché à un autre outils qui renvoie ce genre d'exception, etc. L'IOException est liée au choix technique d'utiliser des libriarie qui remontent ça. L'appelant s'en contre fou. Il dois savoir que la conversion n'a pas eu lieu et bien sur pourquoi (message).
Quand au ConversionFailed il peux se décliner autant que tu veux:
ConversionFailed -> ConversionReaderFailed, ConversionWriterFailed, etc.
On est sur de l'exemple en une ligne là dans ce que je donnais
Partager