Visualizzare su JLabel dove si trova il file .jar

[andbin]

Questo è il blocco di istruzioni di quel JButton.

Beh, ora è ovviamente chiaro: ButtonCADActionPerformed dichiara di lanciare fuori UnsupportedEncodingException (eccezione "checked") ma tu questo metodo lo richiami da actionPerformed che non dichiara (e NON potrebbe farlo) quella eccezione. Insomma, il compilatore capisce che "a monte" di ButtonCADActionPerformed non c'è né gestione (cattura) né possibilità di uscita della eccezione e pertanto lo segnala come errore di compilazione.

Soluzione? Il UnsupportedEncodingException è relativo al concetto del encoding ma tu hai specificato UTF-8 che è sicuramente supportato (da specifiche Java!) quindi ci si aspetta che con quel "UTF-8" fisso la UnsupportedEncodingException NON verrà mai ragionevolmente lanciata. Pertanto la soluzione è catturare UnsupportedEncodingException nel ButtonCADActionPerformed e nel caso dovesse mai davvero capitare (ma non capiterà poi mai) rilanci fuori un error "grave" come es. InternalError indicando che è successo qualcosa di davvero grave.

I try-catch sono scritti da NetBeans.

E comunque scritto così non è nemmeno corretto al 100%. Prova a domandarti: se il costruttore di PrintWriter lanciasse una eccezione ... cosa succede? Prova a tracciare a mente ...

[Gas75]

Pertanto la soluzione è catturare UnsupportedEncodingException nel ButtonCADActionPerformed e nel caso dovesse mai davvero capitare (ma non capiterà poi mai) rilanci fuori un error "grave" come es. InternalError indicando che è successo qualcosa di davvero grave.

Non è quello che succede nel codice attuale? Il catch di UnsupportedEncodingException sta proprio nel ButtonCADActionPerformed.

Prova a domandarti: se il costruttore di PrintWriter lanciasse una eccezione ... cosa succede? Prova a tracciare a mente ...

Sinceramente la problematica non l'ho analizzata molto, sto focalizzando l'attenzione sull'altro problema...
Non credo però che dal .jar vedrei qualcosa se PrintWriter lanciasse eccezioni, a parte la non esecuzione delle istruzioni. Del resto non sto usando il file che mi genera come output delle eccezioni, ho necessità di dare all'utente uno script da importare in CAD. Forse dovrei aggiungere una JLabel per fargli visualizzare dei codici di errore, un po' come fanno le calcolatrici? Ma se i dati di input sono sempre nel "range" di validità per l'esecuzione delle varie istruzioni, perché dovrei temere delle eccezioni?

[andbin]

Non è quello che succede nel codice attuale? Il catch di UnsupportedEncodingException sta proprio nel ButtonCADActionPerformed.

Ma c'è il throws UnsupportedEncodingException. QUESTO conta per il chiamante. È perfettamente lecito dichiarare una eccezione checked con il throws anche se quel metodo NON la lancia fuori. Questo perché il throws serve solo per avvertire di un possibile, potenziale, "pericolo" di una eccezione.

In senso generale (non è il tuo caso poiché il metodo è privato) un metodo può dichiarare una eccezione checked ma non lanciarla mentre poi in una sottoclasse che ridefinisce quel metodo può davvero realmente lanciarla. Ma il "pericolo" è già noto dalla super-classe quindi un chiamante che invoca il metodo polimorficamente sul tipo della super-classe è avvertito che una qualche implementazione del metodo può lanciare quella eccezione.
Questi sono concetti sulle eccezioni ... da studiare e sapere ....


P.S: soluzione: togli il throws UnsupportedEncodingException

[Gas75]

Questi sono concetti sulle eccezioni ... da studiare e sapere ....

Nulla in contrario, anzi.
Finora ho recuperato testi che trattano, se le trattano, le eccezioni relativamente ad argomenti diversi, in maniera trasversale; che sia giusto farle apprendere così non lo so, di certo io preferirei dei capitoli dedicati e poi la didattica trasversale me la faccio io appena acquisisco padronanza.
Addirittura il materiale didattico Oracle, che dovrebbe essere testo ufficiale per l'esame di certificazione OCA, parla di eccezioni, anzi di exceptions essendo in inglese, senza illustrare il perché se ne prevede una o l'altra. Il tutto è stato poi trattato "en passant" al corso che ho seguito perché argomento di coda...