3. Eccezioni di wrapping

Le eccezioni controllate sembravano interessanti in teoria, ma in pratica si sono rivelate un'enorme frustrazione.

Supponi di avere un metodo super popolare nel tuo progetto. Viene chiamato da centinaia di posti nel tuo programma. E decidi di aggiungervi una nuova eccezione verificata . E può darsi che questa eccezione verificata sia davvero importante e così speciale che solo il main()metodo sa cosa fare se viene rilevata.

Ciò significa che dovrai aggiungere l' eccezione verificata alla throwsclausola di ogni metodo che chiama il tuo metodo super popolare . Così come nella throwsclausola di tutti i metodi che chiamano quei metodi. E dei metodi che chiamano quei metodi.

Di conseguenza, le throwsclausole di metà dei metodi nel progetto ottengono una nuova eccezione verificata . E ovviamente il tuo progetto è coperto da test, e ora i test non vengono compilati. E ora devi anche modificare le clausole di lancio nei tuoi test.

E poi tutto il tuo codice (tutte le modifiche in centinaia di file) dovrà essere rivisto da altri programmatori. E a questo punto ci chiediamo perché abbiamo apportato tante maledette modifiche al progetto? Giorno (i?) Di lavoro e test interrotti, tutto per aggiungere un'eccezione verificata ?

E, naturalmente, ci sono ancora problemi relativi all'ereditarietà e all'override del metodo. I problemi che derivano dalle eccezioni verificate sono molto più grandi del vantaggio. La linea di fondo è che ora poche persone li amano e poche persone li usano.

Tuttavia, c'è ancora molto codice (incluso il codice della libreria Java standard) che contiene queste eccezioni verificate . Cosa si deve fare con loro? Non possiamo ignorarli e non sappiamo come gestirli.

I programmatori Java hanno proposto di racchiudere le eccezioni verificate in RuntimeException. In altre parole, intercetta tutte le eccezioni verificate , quindi crea eccezioni non verificateRuntimeException (ad esempio, ) e lanciale invece. In questo modo assomiglia a questo:

try
{
   // Code where a checked exception might occur
}
catch(Exception exp)
{
   throw new RuntimeException(exp);
}

Non è una soluzione molto carina, ma qui non c'è nulla di criminale: l'eccezione è stata semplicemente inserita in un file RuntimeException.

Se lo desideri, puoi recuperarlo facilmente da lì. Esempio:

Codice Nota
try
{
   // Code where we wrap the checked exception
   // in a RuntimeException
}
catch(RuntimeException e)
{
   Throwable cause = e.getCause();
   if (cause instanceof Exception)
   {
      Exception exp = (Exception) cause;
      // Exception handling code goes here
   }
}







Ottenere l'eccezione memorizzata all'interno dell'oggetto RuntimeException. La causevariabile potrebbe null

determinarne il tipo e convertirla in un tipo di eccezione verificato .