Sì, dovresti documentare tutte le eccezioni che un metodo può lanciare i client del metodo devono gestire . Dove esattamente le eccezioni hanno origine è irrilevante, anche se provengono da qualche methodC() che è chiamato da methodB() .

La chiamata di codice methodA() non dovrebbe interessare a quali altri metodi chiama per portare a termine il lavoro, ma è necessario conoscere le cose che potrebbero andare storte.

Nel tuo esempio, poiché methodA() non si assume la responsabilità della gestione delle eccezioni FileNotFound o ResourceNotFound , qualsiasi codice che chiama methodA() deve sapere che deve gestire tali scenari.

Ora, se methodA() può prendere qualche azione ragionevole nel caso di un'eccezione FileNotFound o ResourceNotFound , allora dovrebbe farlo e non ha bisogno di riportare tali eccezioni - può nasconderle dal suo clienti.

Un semplice esempio, in Java: (Per amor di discussione, ammettiamo che un file inesistente è lungo 0 byte)

int getFileSize(String filename) {
    try {
        return getFileBytes(filename).length;
    } catch (FileNotFoundException e) {
        return 0;
    }
}

byte[] getFileBytes(String filename) throws FileNotFoundException {
    // ...
}

Modifica

Come illustrato dal commento di Bobson, ho sentito di aver travisato un punto molto importante - guarda il cambiamento in grassetto sopra!

Generalmente ci sono 3 casi in cui un'eccezione / errore dovrebbe essere lanciata:

1. Cose che puoi ragionevolmente aspettarti di sbagliare. per esempio. Cercando di stampare qualcosa ma non puoi accedere a una stampante o stai tentando di aprire un file che non esiste.
2. Errori di programmazione - cioè bug. per esempio. Dividere per 0, NullPointerExceptions. Questi non dovrebbero trasformarlo in codice rilasciato, quindi in genere non dovresti scrivere codice per gestirli.
3. Errori irrecuperabili. per esempio. StackOverflowError. Questi tendono ad essere lanciati dal sistema sottostante (macchina virtuale, sistema operativo, ecc.) E generalmente non c'è nulla che tu possa fare per loro.

Quelli che dovresti dichiarare sono quelli della categoria 1. Java prova a ti obbliga a fare questo , ma ha alcuni problemi .

Immagina che domani cambierai methodA in modo che l'inizializzazione possa generare un'eccezione. Lo documenterai?

Che cosa succede se modifichi methodA in modo che rilevi una delle eccezioni di methodB e riprova?

Penso che dovresti copiare e incollare le clausole @throws da methodB e tenerle aggiornate con lo stato di methodA .

Uno dei vantaggi è che il tuo IDE ti mostrerà prontamente il javadoc completo e corretto di methodA , e non dovrai pensare o ricordare dettagli di implementazione.

U cattura l'eccezione generata dal metodo B e prende i passaggi necessari nel metodo A. Quindi, se è necessario e inevitabile, U può lanciare un'eccezione dello stesso tipo o di un altro tipo dal metodo A e documentare su quell'eccezione per il metodo A.