PPX.4 Eccezioni .

PROCEDURE PARZIALI SONO EFFICENTI MA MENO SICURE IN CASO DI ERRORI, LE TOTALI SI

Partial procedures are generally a bad idea, however, since there is no guarantee that their arguments (input) are in the permitted subset and the procedure may therefore be called with arguments outside the subset. When this happens, the procedure is allowed to do anything: it might loop forever or return an erroneous result

💡

Rendere una procedura parziale, totale non significa che non necessita di requires, al contrario devo inserirli e specificare come gestisco l’errore

IN CHE MODO UNA PROCEDURA TOTALE PUO’ GESTIRE GLI ERRORI?

Informo l’utente/programma ritornando un particolare valore specifico per indicare la presenza di un determinato errore, ma non è ottimale pk il programmatore potrebbe ignorare l’errore per sbaglio senza saperlo

SOLUZIONE = ECCEZIONI

An exception mechanism allows a procedure to terminate either normally, by returning a result, or exceptionally (la gestione dell’errore è separata dal flusso del programma)

public static int fact (int n) throws NonPositiveException

throw clause → indica che una procedura può contenere una o più eccezioni, il cui nome va specificato e se si verificano le individua.

a quel punto si verifica la propagazione dell’eccezione, ovvero l’eccezione ritorna ai metodi chiamanti finchè trova un try catch che se ne occupi.

se segue un try catch, la presenza della catch implica che il programma continua il suo flusso d’esecuzione pk da per scontato che il problema sarà risolto al suo interno. Anche se un'eccezione è stata catturata, non significa necessariamente che sia stata "risolta" in modo significativo ed il programma potrebbe continuare ma comportarsi in modo imprevedibile.

se non segue nulla manda un messaggio di errore e blocca il programma

poi ci metto le specifiche: le eccezioni controllate (checked exceptions) devono essere dichiarate nel metodo, mentre le eccezioni non controllate (unchecked exceptions) non necessitano di specifiche nell'header del metodo.

try catch


try {
            // Solo il codice che può generare un'eccezione
            result = a / b; // Questo può generare un'eccezione ArithmeticException
        } catch (ArithmeticException e) { 
                    // Gestione dell'eccezione, 
                    //anche usando la variabile e
            System.out.println("Errore: non puoi dividere per zero!"); // Messaggio di errore
            return; // Esci dal metodo se c'è un errore
      }

anche se non c’è il throw, si verifica la propagazione dell’errore

} catch (ArithmeticException e) { : La variabile e è l'oggetto dell'eccezione (che è una classe), non viene inizializzata esplicitamente nel senso tradizionale, poiché viene creata e assegnata automaticamente quando si verifica un'eccezione.

TIPI DI ECCEZIONI EQUANDO USARLI

ogni errore è di tipo throwable ovvero può essere individuato dalla throw cluse

ECCEZIONI CONTROLLATE (individuate in fase di compilazione)

Vanno gestite esplicitamente, altrimenti da errore alla compilazione. Gestirle con la throw clause significa che il metodo può dichiarare esplicitamente la presenza di un errore. A quel punto il chiamante del metodo dovrà gestire l’errore
con un blocco try-catch oppure dichiararlo a sua volta

Se ci sono situazioni (prevedibili) che non puoi controllare facilmente e che possono portare a errori, come l'accesso a file o risorse esterne, le eccezioni controllate sono più appropriate. Queste eccezioni devono essere gestite dal chiamante, il che offre un livello di sicurezza aggiuntivo.

ECCEZIONI NON CONTROLLATE (individuate in fase di esecuzione → RuntimeExeption)

Non devi necessariamente gestirle con la throw cluse pk è questione di sistemare un attimo il programma.

Usa eccezioni non controllate quando ti aspetti che gli sviluppatori scrivano il codice in modo tale da garantire che l'eccezione non si verifichi. (situazioni inattese)

ERRORS

Non si possono gestire in alcun modo e terminano il programma

ESEMPIO DI ECCEZIONE PERSONALIZZATA

QUALE COSTRUTTORE?

vuoto (1° caso) se nn ho dettagli sull’errore o sono irrilevanti

con argomento (2° caso)

entrambi implementando i casi in cui specificare una o l’altra

PK CREARE UNA ECCEZIONE?

Pk con quelle predefinite:

non possono gestire situazioni specifiche del contesto del programma, quindi ne creo di nuove.

non possono fornire messaggi di errore più chiari e contestualizzati

le personalizzate possono essere gestite in modo più flessibile

Nel momento in cui creo un eccezione , creo una nuova classe pubblica (quindi in un altro file pk un file può contenere una sola classe pubblica, il main è un metodo), e con extend specifico se appartiene alla categorie delle eccezioni controllate (Exeption) oppure alla sezione delle eccezioni non controllate (RuntimeException) per mezzo della key word extends.

Che senso ha creare un eccezione RuntimeExeprion se basta correggere il codice?

Se vengono create vuol dire che il debug non è stato ancora eseguito per determinati scenari o forse si preferisce tenere un codice semplice pk gestire ogni eccezioni complica il programma o altre ragioni.

REFLECTION(quano faccio throw) VS MASKING(quando faccio try e catch)

riflessione → propagazione automatica oppure rilancio dell’eccezione con un nome più più specifico e contestualizzato


public class MinArray {

    // Metodo per trovare il valore minimo
    public static int findMin(int[] array) throws EmptyArrayException {
        try {
            // Controlliamo il primo elemento dell'array
            return array[0]; // Questo lancerà un IndexOutOfBoundsException se l'array è vuoto
        } catch (IndexOutOfBoundsException e) {
            // Invece di riflettere l'eccezione, lanciamo una nuova eccezione
            throw new EmptyArrayException("L'array è vuoto. Impossibile trovare il minimo.");
        }
    }

    public static void main(String[] args) {
        int[] emptyArray = {}; // Array vuoto

        try {
            // Proviamo a trovare il valore minimo dell'array vuoto
            int minValue = findMin(emptyArray); 
            //quando chiami il metodo findMin all'interno di un blocco try, stai dicendo a Java di "provare" ad eseguire quel codice.
            //se mi da errore lo rilancio indietro con un nome più chiaro semanticamente pk l'ho creato io per questo caso preciso
            System.out.println("Il valore minimo è: " + minValue);
        } catch (EmptyArrayException e) {
            // Gestiamo l'eccezione personalizzata
            System.out.println("Errore: " + e.getMessage());
        }
    }
}