[Domande teoriche] Java e programmazione ad oggetti

[D4rkAng3l]

Salve,
allora devo dare un esame di Linguaggi di programmazione che comprende un primo esame scritto di teoria ed eventualmente (se passo il primo) un successivo secondo esame scritto di pratica in JAVA (che palle 2 esami per uno stesso corso...)

Il primo esame teorico oltre a degli esercizzi (assembler, far vedere cosa succede in memoria nello stack e nell'heap, etcetc) è composto anche da domande teoriche...mi dite se secondo voi la risposta a questa può essere corretta o se c'è da integrare con qualcosa in più?

1) Cosa sono le eccezioni in un linguaggio di programmazione? In che senso si afferma che: "un'eccezione rimanda al contesto superiore" ?

Io direi: Le eccezioni sono delle situazioni impreviste ed eccezionali che possono verificarsi all'interno di una routine (o metodo) che potenzialmente potrebbero rivelarsi pericolose.
Per esempio se ho una classe Frazione che rappresenta frazioni mediante 2 variabili di istanza intere: numeratore e denominatore...se tento di creare un oggetto Frazione con denominatore nullo lancio un'eccezione poichè altrimenti creerei un oggetto sbagliato.

Le eccezioni quindi sono usate quando un metodo si trova a dover gestire una situazione che non capisce edx invece di bloccare la computazione comunica a chi lo ha invocato il metodo che non riesce ad eseguire e proprio in questo senso le eccezioni rispondono al contesto superiore.

Ad esempio nello stack ho che il metodo main() chiama un metodo A che a sua volta chiama un metodo B in cui viene lanciata un'eccezione che viene rimandata ad A. Quando A riceve un'eccezione può fare 3 cose:

1) A non sà che fare --> Rimanda l'eccezione al contesto superiore cioè il main()
2) A sà che fare: risolve il problema e richiama il metodo B
3)A capisce che si tratta di un errore fatale e blocca la computazione.

Se un'eccezione continua ad essere mandata al proprio contesto superiore prima o poi arriverà al main che essendo un metodo si comporta come gli altri rimandandolo al cotesto superiore o killando il processo in quanto nel main èla stessa cosa...perchèil suo contesto superiore è la JVM che terminerebbe il processo.

Le eccezioni sono quindi un MECCANISMO DI RETURN ALTERNATIVO

Grazie
Andrea

[agente mm8]

Mi sebra fatto bene...
Io però all'ultima frase aggiungerei:
Le eccezioni sono quindi un MECCANISMO DI RETURN IN CASO DI ERRORE
Poi non so, essendo in terza media, non ho mai affrontato esami del genere

[cionci]

Il meccanismo di return passa l'esecuzione al chiamante in un punto prestabilito. Le eccezioni invece interrompono l'esecuzione e risalgono lo stack di chiamata fino ad incontrare un catch che blocca la risalita. Di fatto quindi la differenza fra un meccanismo di return ed un meccanismo di eccezione è abissale, perché con un return sai a chi ritorna l'esecuzione, con un'eccezione no ;)

Concordo anche nel modificare l'ultima frase, anzi la toglierei proprio.

[shinya]

Il meccanismo di return passa l'esecuzione al chiamante in un punto prestabilito. Le eccezioni invece interrompono l'esecuzione e risalgono lo stack di chiamata fino ad incontrare un catch che blocca la risalita. Di fatto quindi la differenza fra un meccanismo di return ed un meccanismo di eccezione è abissale, perché con un return sai a chi ritorna l'esecuzione, con un'eccezione no ;)

Questo è vero. Ma si può "rimediare", volendo.
A me personalmente piace limitare al massimo i side effect; se so che una funzione può fallire, faccio qualcosa del genere. (pseudo-java)

// metodo che può fallire
final Either<Result, Exception> iCouldFail() {
try {
...
return Either.right(new Result()); // tutto bene
} catch (final APossibleException ex) {
return Either.left(ex);
}
}

// e poi lo uso cosi - il "punto di ritorno" è sempre e solo uno
final Either<Result, Exception> value = iCouldFail();
if value.isRight() {
// tutto ok
}
else {
// gestisci l'errore
}


Se java supportasse il pattern matching sarebbe meno verboso...
Ma questo è solo il mio personalissimo gusto eh...preso in prestito da haskell :)

[banryu79]

...

Tecnica interessante, shinya.
Ho una domanda: se capita che il tuo metodo ICouldFail() al suo interno esegua codice che potenzialmente può generare, diciamo 3 tipi diversi di checked exception, e il chiamante debba gestire in modo diverso tutti e tre i casi?

[shinya]

Tecnica interessante, shinya.
Ho una domanda: se capita che il tuo metodo ICouldFail() al suo interno esegua codice che potenzialmente può generare, diciamo 3 tipi diversi di checked exception, e il chiamante debba gestire in modo diverso tutti e tre i casi?

Beh considera che non è una tecnica che uso sempre... anche perchè java è quel che è, e uscire troppo dai binari può costare caro in termini di comprensibilità del codice (soprattutto per qualcun'altro che non ha dimestichezza con un pò di programmazione funzionale).
Una strada che mi viene in mente, sempre per usare questa "tecnica" nello scenario che hai dipinto tu, è di wrappare tutte le eccezzioni in una di più alto livello e lanciare quella. Poi dal chiamante gestire i vari casi (via instanceof, ma anche no, o via polimorfismo, con un metodo per ogni eccezione).

Ma ovviamente bisognerebbe valutare sul momento se usare un approccio tradizionale o altro. Comunque se ti interessa c'è una libreria che fornisce già tutti questi "pattern" presi in prestito da haskell (e amici)... che è questa qua: http://functionaljava.org/

[banryu79]

Una strada che mi viene in mente, sempre per usare questa "tecnica" nello scenario che hai dipinto tu, è di wrappare tutte le eccezzioni in una di più alto livello e lanciare quella. Poi dal chiamante gestire i vari casi (via instanceof, ma anche no, o via polimorfismo, con un metodo per ogni eccezione).

Ecco, proprio come pensavo, solo che così diventa molto "verboso" (e instanceof non mi piace tantissimo, preferisco la versione polimorfica).
Comunque è un limite/caratteristica di Java: volevo solo sapere se c'erano modi più "furbi" (più snelli) per farlo e non ne ero sicuro.
Grazie per la delucidazione.


Ma ovviamente bisognerebbe valutare sul momento se usare un approccio tradizionale o altro. Comunque se ti interessa c'è una libreria che fornisce già tutti questi "pattern" presi in prestito da haskell (e amici)... che è questa qua: http://functionaljava.org/

Interessante, me la guardo; grazie per la risorsa :)