6 eccezioni Java che tormentano i principianti Java.
(Originale) (Sono nuovo sia in Java che in inglese, quindi sarò felice di ricevere critiche e aiuto)
Sia prima che adesso, mi imbatto in molti neofiti di Java che hanno problemi con alcune eccezioni comuni che devo spiegare ancora una volta. Credo che altri sviluppatori Java senior abbiano lo stesso problema nel tentativo di aiutare i principianti ad affrontare queste eccezioni. Pertanto, ho scritto questo articolo per il mio sviluppo. Non esitate a commentare questo articolo o aggiungere eccezioni all'elenco seguente.
Questa è una di quelle eccezioni, con un messaggio come
"Exception in thread "main" NoClassDefFoundError" , che la maggior parte dei nuovi sviluppatori Java incontra nel mondo della programmazione Java. Un principiante scrive un programma che visualizza “Hello world!”, va alla riga di comando, digita “java…”, preme invio e BAM! =). E capire come far stampare al programma "Hello world!" sul monitor, richiede del tempo.
NoClassDefFoundError si verifica quando Java Virtual Machine (JVM) tenta di accedere a una classe in fase di avvio e la classe non viene trovata, anche se la stessa classe è stata trovata in fase di compilazione. Molto spesso questa eccezione si verifica quando si tenta di eseguire un programma utilizzando il comando "java" e il classpath non è impostato correttamente. Di seguito è riportata una descrizione dei motivi per cui si verifica questa eccezione.
- La classe non è disponibile in -classpath.
- La variabile d'ambiente CLASSPATH è stata sovrascritta. Puoi verificarne la presenza e la correttezza utilizzando il comando di Windows “set”.
La soluzione al problema è descritta più dettagliatamente
qui.
Inoltre, è necessario comprendere la differenza tra la variabile d'ambiente CLASSPATH e la chiave dell'interprete -classpath. I professionisti sconsigliano l'utilizzo di CLASSPATH. Il modo migliore è passare la chiave -classpath all'interprete.
ClassNotFoundException è un'altra eccezione che diventa un incubo per un principiante non appena inizia a programmare. È interessante notare che lo sviluppatore Java medio spesso
viene confuso tra le eccezioni ClassNotFoundException e NoClassDefFoundError . E così, la differenza tra queste due eccezioni resta
una delle domande più frequenti nei colloqui per la posizione Junior .
ClassNotFoundException si verifica quando la JVM tenta di caricare una classe specifica e non la trova nel classpath. Uno dei luoghi comuni in cui un nuovo sviluppatore Java lo incontra per la prima volta è la connessione a un database utilizzando la libreria JDBC. Lì proveremo a caricare il driver utilizzando codice come Class.forName("JDBCdriver"). Un buon articolo su ClassNotFoundException è
qui . Cercare di comprendere il concetto di
Java Classloader è il metodo più efficace per affrontare questo problema. Puoi leggere
come configurare il classpath Java in ambiente Win/Unix . Come indicato nei
documenti Java , si verifica un'eccezione nei seguenti casi:
- Si tenta di caricare una classe utilizzando il metodo Class.forName e il file .class non è nel classpath. Questo è lo scenario più comune dei tre elencati qui.
- Quando il caricatore di classi tenta di caricare una classe utilizzando loadClass.
- Quando il caricatore di classi tenta di caricare una classe utilizzando findSystemClass.
Questa eccezione è più facile da comprendere per i principianti rispetto alle prime due. Inoltre,
questa eccezione è facilmente identificabile perché quando si verifica, il messaggio relativo all'eccezione
indica il numero di riga del programma in cui si è verificata. Questa eccezione si verifica quando la JVM tenta di accedere a un oggetto o tenta di chiamare un metodo su un oggetto e riceve un valore null invece di un riferimento all'oggetto. Il Java Doc indica anche i seguenti motivi:
- Accesso o modifica di un metodo su un oggetto non valido. (cioè invece di un riferimento a un oggetto JVM ottiene null)
- Ottenere la lunghezza di un array quando non è valido. (non inizializzato ad esempio)
- È stato effettuato un tentativo di accesso a un elemento di array inesistente di tipo Object. (cioè quando, invece di un riferimento a un oggetto, l'elemento dell'array contiene null)
Il metodo più semplice per evitare questa eccezione è utilizzare un controllo non NULL. Tuttavia, prima o poi, questa diventa una pratica di sviluppo Java e troverai controlli non NULL ovunque. È interessante notare che
l'inserimento di controlli non NULL ovunque non è considerato un buon stile di programmazione . E il motivo principale per utilizzare il controllo non NULL è che lo sviluppatore desidera passare un oggetto null in caso di fallimento o errore. Invece, è
una buona pratica di programmazione che i programmatori dovrebbero utilizzare
restituire un oggetto vuoto, anziché un valore nullo , come logica di base per il comportamento di un programma in caso di errore. Tuttavia, adottare questa pratica di programmazione è più difficile di quanto sembri.
C'è un buon articolo su questo sulla nostra risorsa.
Questa è un'altra eccezione familiare ai principianti, che si verifica quando si tenta di lanciare un oggetto in una classe che non è una sua sottoclasse. Ancora una volta, questo è abbastanza facile da capire, identificare e semplice da risolvere. Un modo per evitare questa eccezione quando il tipo dell'oggetto è sconosciuto in fase di esecuzione è utilizzare
"InstanceOf" per verificare che l'oggetto sia un'istanza di una particolare classe.
Questa eccezione è autoesplicativa e si verifica quando la JVM tenta di accedere a un elemento dell'array con un indice inesistente, come negativo (-1) o maggiore o uguale alla dimensione dell'array.
È abbastanza facile da capire, definire e correggere . Ad esempio, quando si crea un ciclo,
for (i = 0; i <= cmd_stack.length; i++) System.out.println(cmd_stack[i]); si verifica un'eccezione, perché nell'array gli indici iniziano da 0 e il metodo length restituisce il numero di elementi e il numero è 1 maggiore del valore dell'ultimo indice. Utilizzo corretto
for (i = 0; i < cmd_stack.length; i++) System.out.println(cmd_stack[i]);
Questa eccezione è meno comune ed è abbastanza facile da comprendere, identificare e risolvere. Si verifica quando la JVM tenta di chiamare un metodo inesistente o un metodo con un argomento non valido.
GO TO FULL VERSION