Generare e catturare eccezioni nella stessa funzione / metodo

Ho scritto una funzione che richiede all'utente un input fino a quando l'utente non inserisce un numero intero positivo (un numero naturale). Qualcuno ha detto che non avrei dovuto gettare e catturare eccezioni nella mia funzione e che avrei dovuto gestirle il chiamante della mia funzione.

Mi chiedo cosa ne pensano gli altri sviluppatori. Probabilmente sto anche abusando delle eccezioni nella funzione. Ecco il codice in Java:

private static int sideInput()
{
    int side = 0;
    String input;
    Scanner scanner = new Scanner(System.in);

    do {
        System.out.print("Side length: ");
        input = scanner.nextLine();
        try {
            side = Integer.parseInt(input);
            if (side <= 0) {
                // probably a misuse of exceptions
                throw new NumberFormatException();
            }
        }
        catch (NumberFormatException numFormExc) {
            System.out.println("Invalid input. Enter a natural number.");
        }
    } while (side <= 0);

    return side;
}

Sono interessato a due cose:

1. Devo lasciare che il chiamante si preoccupi delle eccezioni? Il punto della funzione è che assilla l'utente finché l'utente non inserisce un numero naturale. Il punto della funzione è negativo? Non sto parlando dell'interfaccia utente (l'utente non è in grado di uscire dal ciclo senza l'input corretto), ma dell'input in loop con le eccezioni gestite.
2. Diresti che la dichiarazione di lancio (in questo caso) è un abuso di eccezioni? Potrei facilmente creare un flag per verificare la validità del numero e generare il messaggio di avviso basato su quel flag. Ma ciò aggiungerebbe più righe al codice e penso che sia perfettamente leggibile così com'è.

Il fatto è che scrivo spesso una funzione di input separata. Se l'utente deve inserire un numero più volte, creo una funzione separata per l'input che gestisce tutte le eccezioni e limitazioni di formattazione.

Il punto di un'eccezione è che consente a un metodo di dire a quel chiamante che è entrato in uno stato in cui non potrebbe continuare normalmente, senza costringere l'utente a incorporare un codice di errore nel valore restituito.

Nel tuo caso, il tuo metodo sa esattamente cosa fare quando l'input non è maggiore di 0. L'unico motivo per cui stai salvando le righe qui è perché ti capita di lanciare la stessa eccezione che otterresti se l'input non fosse un numero. Tuttavia, l'eccezione che stai generando non rappresenta correttamente il motivo per cui al tuo codice non piace l'input. Se qualcun altro dovesse venire a vedere questo codice, dovrebbe passare del tempo extra cercando di vedere esattamente come funzionano le cose.

Questo è un cattivo uso delle eccezioni. Per cominciare, un numero non positivo non è un'eccezione di formato.

Perché usare le eccezioni? Se sai quale input non è consentito, non uscire dal ciclo fino a quando non ottieni un input valido dall'utente, simile al seguente:

while (true)
{
   // Get user input.
   String input = scanner.nextLine();

   try
   {
      side = Integer.parseInt(input);

      break;
   }
   catch (NumberFormatException ex)
   {
      // Inform user of invalid input.
      System.out.println("Invalid input. Enter a natural number.");
   }
}

Cattura le eccezioni solo se intendi fare qualcosa che è rilevante per la chiamata del metodo corrente; cioè pulizia, logica di errore, ecc. In questo caso, il fermo sta semplicemente inviando un messaggio alla console, non è rilevante per il metodo sideInput, quindi può essere gestito più in alto nella catena / stack di chiamate.

Si può sbarazzarsi del tentativo / cattura qui e semplicemente documentare la chiamata del metodo:

//Throws NumberFormatException if read input is less than 0
private static int sideInput()

Bisogna ancora gestire quell'eccezione più in alto nella catena / stack di chiamate!

Non dovresti lanciare e catturare la stessa eccezione in un metodo, penso anche che il blocco catch catturi la stessa eccezione che stai lanciando, quindi non lo stai davvero lanciando.

Se ha parseIntavuto successo, allora non è un NumberFormatException.

se side è inferiore a zero, dovresti lanciare a NegativeSideLengthException;

Crea un'eccezione personalizzata / commerciale denominata NegativeSideLengthException

public class NegativeSideLengthException extends Exception
{


    public NegativeSideLengthException(Integer i)
    {
        super("Invalid negative side length "+i);        
    }

}

Quindi sideInputgenera NegativeSideLengthException

private static int sideInput() throws NegativeSideLengthException
{
    int side = 0;
    String input;
    Scanner scanner = new Scanner(System.in);

    do {
        System.out.print("Side length: ");
        input = scanner.nextLine();
        try {
            side = Integer.parseInt(input);
            if (side <= 0) {
                throw new NegativeSideLengthException(side);
            }
        }
        catch (NumberFormatException numFormExc) {
            System.out.println("Invalid input. Enter a natural number.");
        }
    } while (side <= 0);

    return side;
}

Puoi anche (se vuoi) aggiungere un altro blocco catch per catturare NegativeSideLengthExceptione non avere il metodo lanciarlo.

do {
    System.out.print("Side length: ");
    input = scanner.nextLine();
    try {
        side = Integer.parseInt(input);
        if (side <= 0) {
            throw new NegativeSideLengthException(side);
        }
    }
    catch (NumberFormatException numFormExc) {
        System.out.println("Invalid input. Enter a natural number.");
    } catch (NegativeSideLengthException e){
        System.out.println("Invalid input. Enter a non-negative number.");
    }
} while (side <= 0);

Le bandiere non sono un buon modo per gestire le eccezioni.

Le eccezioni sono cose piuttosto da incubo, portano più complessità di quelle che risolvono.

In primo luogo, se non cogli le tue eccezioni, il chiamante può fare solo on error resume next, cioè dopo una settimana, anche tu non saprai cosa può lanciare la tua funzione e cosa farne:

{
    ...
}
catch(OutOfMemory, CorruptedMemory, BadData, DanglingPointers, UnfinishedCommit)
{
    Console.WriteLine("Nothing to see here, move on.");
    Console.WriteLine("The app is very stable, see, no crashing!");
}

Fondamentalmente, se li prendi, devi avere un'ottima conoscenza dei contratti e garanzie di eccezione. Ciò accade raramente in un mondo reale. E anche il tuo codice sarà difficile da leggere.

Inoltre, la cosa divertente è che se hai davvero la possibilità di gestire le eccezioni hai bisogno del vero linguaggio RAII, che è una specie di umorismo, dal momento che Java e .NET si basano su eccezioni ...

Ripetendolo ancora una volta, ma ...:

http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/118161.aspx

http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx

http://www.joelonsoftware.com/items/2003/10/13.html