I metodi dovrebbero restituire solo un'eccezione della propria classe di eccezioni?

3

Considera il seguente frammento di codice:

class Foo {
  Baz baz;
  // ...

  void bar() {
    int p = this.baz.doSomething();

    if (p == this.x) {
      throw new FooException('Invalid values', FooException::INVALID_VALUES);
    }

    this.x = p * this.y;
  }
  // ...
}

Baz::doSomething() può generare eccezioni del tipo BazException .

Questo fa sì che Foo::bar() lanci entrambi i tipi di eccezioni, del tipo FooException e BazException .

È accettabile avere questo tipo di metodi, o i metodi di un'eccezione devono essere generati solo dal proprio tipo di eccezione? Un esempio di ciò con la funzione bar riscritta è la seguente:

void bar() {
  try {
    int p = this.baz.doSomething();
    if (p == this.x) {
      throw new FooException('Invalid values', FooException::INVALID_VALUES);
    }
  }
  catch (BazException be) {
    throw new FooException('Invalid values', FooException::INTERNAL_ERROR);
  }
}
    
posta user2064000 30.09.2016 - 06:50
fonte

1 risposta

4

Perché utilizziamo diversi tipi di eccezione? Potremmo anche usare un singolo tipo per tutte le eccezioni, ad es. Java's RuntimeException.

Il punto è che possiamo filtrare le eccezioni in una clausola catch in modo che prendiamo solo quelle eccezioni che possiamo gestire. Non è ragionevole rilevare errori logici, possono essere risolti solo cambiando il programma. Non è ragionevole raccogliere gli errori di convalida degli argomenti, a meno che non siano stati causati dall'input dell'utente. Sembra che il tag type INVALID_VALUES e INTERNAL_ERROR debbano essere il tipo di eccezione, non FooException. In particolare, preferisci le eccezioni delle librerie standard in cui la gestione dell'eccezione standard avrebbe anche senso per il tuo errore.

L'acquisizione di eccezioni per reinserirle in un altro tipo di eccezione è OK se riesci ad aggiungere il contesto, ad es. "Errore durante l'aggiornamento di Bazzes". Tuttavia, il tipo di eccezione o il messaggio non dovrebbero essere usati per individuare l'esatto percorso del codice sorgente dell'errore - questo è il significato delle tracce dello stack. Dobbiamo fare molta attenzione a mantenere l'eccezione originale e la traccia dello stack. Le eccezioni di libreria standard di Java possono richiedere un Throwable cause nei loro costruttori. Se crei classi personalizzate, dovresti farlo anche tu. Attualmente, stai scaricando tutte le preziose informazioni di debug.

    
risposta data 30.09.2016 - 07:39
fonte

Leggi altre domande sui tag