Che cosa significa quando il metodo principale genera un'eccezione?

Question

Sto rivedendo un seminario intermedio che ho preparato per l'esame finale domani mattina. Ho sbagliato questa domanda, ma non c'è una risposta corretta, e ho trascurato di chiedere al prof.

Si consideri il seguente frammento di codice:

public static void main(String[] args) throws FileNotFoundException 

Quale delle seguenti affermazioni di questo codice è corretto?

1. Il metodo principale è progettato per intercettare e gestire tutti i tipi di eccezioni.
2. Il metodo principale è progettato per intercettare e gestire FileNotFoundException.
3. Il metodo principale dovrebbe terminare semplicemente se si verifica FileNotFoundException.
4. Il metodo principale dovrebbe terminare semplicemente se si verifica un'eccezione.

Avevo scelto la seconda opzione.

Answer 1

risposta è il numero 4,

4.- Il metodo principale dovrebbe semplicemente terminare se si verifica alcuna eccezione.

La clausola throws indica solo che il metodo genera un'eccezione FileNotFoundException e che il metodo di chiamata deve catturarlo o ricrearlo. Se un'eccezione non controllata viene lanciata (e non catturata) nel metodo principale, verrà chiusa.

Controllare questo test:

public class ExceptionThrownTest { 

    @Test 
    public void testingExceptions() { 

     try { 
      ExceptionThrownTest.main(new String[] {}); 
     } catch (Throwable e) { 
      assertTrue(e instanceof RuntimeException); 
     } 

    } 

    public static void main(String[] args) throws FileNotFoundException { 

     dangerousMethod(); 

     // Won't be executed because RuntimeException thrown 
     unreachableMethod(); 

    } 

    private static void dangerousMethod() { 
     throw new RuntimeException(); 
    } 

    private static void unreachableMethod() { 
     System.out.println("Won't execute"); 
    } 
} 

Come si può vedere, se mi passi un RuntimeException il metodo terminerà anche se l'eccezione generata non è un FileNotFoundException

Answer 2

Il metodo principale non è la cattura eccezioni , invece, gestisce lo FileNotFoundException lanciandolo all'origine che ha invocato il metodo principale.

Il runtime di sistema avvia le classi JVM, una classe specifica tra le classi JVM richiama il metodo principale.

In questo caso, la gestione del metodo principale throws è in balia delle classi JVM.

• È possibile leggere a riguardo nello Java language specification fornito da Oracle.
• Inoltre è possibile visualizzare il codice sorgente per alcune delle JVM disponibili là fuori, facendo quel percorso ti porta via ad altri linguaggi di programmazione, OpenJdk.

ho pensato di condividere la mia piccola crosta di ricerca umiliato in questo argomento, spero che aiuta i curiosi :)

Answer 3

Amico, un po 'in ritardo, ma la risposta è il numero 3.

numero 1 è falso perché non gestisce FileNotFoundException

Numero 2 è falsa per lo stesso motivo.

Il numero 3 è vero. Se viene generata un'eccezione FileNotFoundException, il metodo principale verrà terminato.

Il numero 4 è falso. Non terminerebbe in QUALUNQUE eccezione. Sarebbe terminato solo in caso di eccezione non verificata o FileNotFoundException. Se non ci sono altre eccezioni controllate dichiarate nella clausola 'tiri', significa che vengono gestite all'interno del metodo.

Answer 4

Anche se una risposta è già stato scelto per questa domanda, credo che la risposta corretta per il test è il numero 3:

3. Il metodo principale dovrebbe semplicemente terminare se si verifica l'eccezione FileNotFoundException.

perché dice dovrebbe, non sarebbe .
Voglio dire, il codice nel metodo può catturare qualsiasi eccezione, sia selezionata che deselezionata, e o, deglutire, recuperare o rilanciarlo — oppure non riuscire a prenderli affatto.

Ma se raggiunge uno FileNotFoundException senza (ri) lanciarlo, sta infrangendo il proprio contratto: qualsiasi chiamante non vedrà l'eccezione come indicato nella firma del metodo, perché il metodo lo ha gestito (forse anche il compilatore potrebbe lamentarsi in quel caso, dicendo che l'eccezione non viene mai lanciata, ma non sono sicuro che qui).

Penso che il vostro seminario abbia posto una domanda sul design piuttosto che su una specifica implementazione.

Answer 5

Sono d'accordo con alcune altre risposte che la risposta corretta alla domanda è l'opzione 3. Opzione 4 dice:

4. Il principale metodo dovrebbe semplicemente sospendere se si verifica alcuna eccezione .

Nota "qualsiasi" in questa opzione. Ecco un esempio di codice in cui si verifica un'eccezione, ma main() non termina:

public static void main(String[] args) throws FileNotFoundException { 
    try { 
     methodThatThrowsACheckedException(); 
    } catch (SomeCheckedException e) { 
     // do something to handle this exception 
    } 
} 

In questo codice verifica un'eccezione, ma il metodo non termina, come è stato configurato per gestire questa eccezione. Se l'eccezione fosse un UncheckedException non protetto, allora il metodo terminerebbe, ovviamente. Il punto dell'opzione 4, tuttavia, è che qualsiasi contro-esempio lo invalida, poiché dice che si verifica "qualsiasi" eccezione.

opzione 3, tuttavia, limita tale denuncia alle verifica solo quando l'eccezione nella firma del metodo è gettato:

3. Il metodo principale dovrebbe semplicemente terminerà se si verifica l'FileNotFoundException .

La ragione opzione 3 ha più senso è perché il codice come il seguente non ha senso, in pratica:

public static void main(String[] args) throws FileNotFoundException { 
    try { 
     methodThatThrowsFileNotFoundException(); 
    } catch (FileNotFoundException e) { 
     // do something to handle this exception 
    } 
} 

Non ha molto senso per dichiarare che un metodo genera un'eccezione , ma prendi quell'eccezione nel metodo (a meno che, forse, non lo rilasci dopo aver fatto qualcosa, nel qual caso l'opzione 3 rimane valida, come alla fine il metodo alla fine).