Originariamente inviata da
LeleFT
Risposte:
1) No, la "pulizia" del main non c'entra assolutamente. Nel tuo caso, nel main non ci sono blocchi try/catch perchè il codice che tu usi non può in nessun caso lanciare eccezioni checked. L'unico metodo da te usato che può lanciare eccezioni è il metodo aggiungiTesto(String), che però lancia una eccezione unchecked (RuntimeException). Il compilatore guarda solo a cosa tu invochi: se invochi un metodo che dichiara (throws) di poter lanciare eccezioni checked, allora il compilatore ti costringerà ad usare un blocco try/catch o a rilanciare quella/quelle eccezioni dal metodo in cui possono essere sollevate (che sia nel main o in qualunque altro metodo, al compilatore frega nulla).
Se io modificassi il codice in questo modo:
codice:
public class TestFileSorgente {
public static void main(String args[])
{
FileSorgente file = new FileSorgente("File.java",1,"public class TestFileSorgente ");
System.out.println(file.getContenuto());
try
{
file.aggiungiTesto("{");
System.out.println(file.getContenuto());
file.aggiungiTesto(null);
System.out.println(file.getContenuto());
file.aggiungiTesto("}",31);
System.out.println(file.getContenuto());
file.aggiungiTesto("// testo",31);
System.out.println(file.getContenuto());
}
catch(NullPointerException exc)
{
System.out.println("problema con: " + exc.getMessage());
}
catch(StringIndexOutOfBoundsException exc)
{
System.out.println("indice di posizione non valido");
}
}
}
codice:
import java.lang.String;
public class FileSorgente extends File
{
...
public String aggiungiTesto(String testo) throws NullPointerException
{
if (contenuto == null)
{
contenuto = "";
}
if (testo == null)
{
throw new NullPointerException();
}
contenuto += testo;
return contenuto;
}
public String aggiungiTesto(String testo, int posizione) throws NullPointerException, StringIndexOutOfBoundsException
{
int length = contenuto.length();
if(contenuto==null)
{
contenuto="";
}
if(testo==null)
{
throw new NullPointerException();
}
if(posizione < 0 || posizione > length)
{
throw new StringIndexOutOfBoundsException();
}
contenuto = contenuto.substring(0, posizione) + testo + contenuto.substring(posizione);
return contenuto;
}
...
Sarebbe concettualmente corretto? Dico concettualmente perchè sembra funzionare
Originariamente inviata da
LeleFT
2) Premesso che catturare e gestire una NullPointerException nel 99% dei casi non ha alcun senso (preciso dopo), non è vero che tu non puoi creare un oggetto FileSorgente con contenuto nullo. Prova così:
codice:
FileSorgente sorg = new FileSorgente("pippo.java", 1, null);
Questo codice è perfettamente lecito, compila e ti riporta esattamente nel caso in esame.
ah già, è vero. mi era sfuggito. grazie.
Avrei una domanda però:
In questo esempio
codice:
public PortaMonete(int... valori)
{
...
}
codice:
public class TestMonete
{
public static void main(String args[])
{
PortaMonete portamonete3 = new PortaMonete();
}
}
la creazione del portamonete3 senza specificare alcun campo nel costruttore non mi segnala errori perchè ho utilizzato i varargs?
Originariamente inviata da
LeleFT
Precisazione sulla NPE (NullPointerException): a parte casi particolari (programmi che, generalmente, analizzano sorgenti o servono ad aiutare le fasi di sviluppo o usano dati provenienti da librerie/programmi di terze parti), una NullPointerException rappresenta un
errore nel programma. E un errore non va "gestito": va corretto. Una NPE viene sollevata quando si cerca di usare un oggetto che è nullo. Quando non si è sicuri della reale istanziazione di un oggetto (perchè proviene da codice esterno, di cui non si ha il controllo) ci si dovrebbe fare carico di controllare prima la non nullità del riferimento; se viene sollevata durante l'esecuzione di un programma, allora ci si deve preoccupare di capire perchè quel tale oggetto in quell'istante è nullo. Da questo ne consegue che non ha nessun senso catturare e gestire una NPE.
Ciao.
Il discorso è chiarissimo. Nell'esempio di sopra l'ho usato per evitare di usare un'eccezione più "generica" (RuntimException) visto che in quel caso era abbastanza chiaro quale tipo di eccezione potesse essere sollevata. Magari però era meglio usare una sola RuntimeException che mi avrebbe gestito anche la StringIndexOutOfBoundsException.
Rispondi quotando
