Lanzar y atrapar excepciones en la misma función / método

He escrito una función que le pide al usuario que ingrese hasta que el usuario ingrese un número entero positivo (un número natural). Alguien dijo que no debería lanzar y capturar excepciones en mi función y debería dejar que la persona que llama de mi función las maneje.

Me pregunto qué piensan otros desarrolladores sobre esto. Probablemente también estoy haciendo mal uso de excepciones en la función. Aquí está el código en 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;
}

Me interesan dos cosas:

1. ¿Debo dejar que la persona que llama se preocupe por las excepciones? El punto de la función es que molesta al usuario hasta que el usuario ingrese un número natural. ¿Es malo el punto de la función? No estoy hablando de la interfaz de usuario (el usuario no puede salir del bucle sin la entrada adecuada), sino de la entrada en bucle con excepciones manejadas.
2. ¿Diría que la declaración de lanzamiento (en este caso) es un mal uso de excepciones? Podría crear fácilmente una bandera para verificar la validez del número y enviar el mensaje de advertencia basado en esa bandera. Pero eso agregaría más líneas al código y creo que es perfectamente legible como es.

La cuestión es que a menudo escribo una función de entrada separada. Si el usuario tiene que ingresar un número varias veces, creo una función separada para la entrada que maneja todas las excepciones y limitaciones de formato.

El punto de una excepción es que permite que un método le diga a la persona que llama que ingresó un estado en el que no puede continuar normalmente, sin obligarlo a incrustar un código de error en el valor de retorno.

En su caso, su método sabe exactamente qué hacer cuando la entrada no es mayor que 0. La única razón por la que está guardando líneas aquí es porque está lanzando la misma excepción que obtendría si la entrada no fuera un número. Sin embargo, la excepción que está lanzando no representa adecuadamente por qué su código no le gusta la entrada. Si alguien más apareciera y viera este código, tendrían que pasar más tiempo tratando de ver exactamente cómo funcionan las cosas.

Este es un mal uso de excepciones. Para empezar, un número no positivo no es una excepción de formato.

¿Por qué usar excepciones en absoluto? Si sabe qué entrada no está permitida, simplemente no salga del ciclo hasta que obtenga una entrada válida del usuario, algo como lo siguiente:

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.");
   }
}

Solo capture excepciones si tiene la intención de hacer algo que sea relevante para la llamada al método actual; es decir, limpieza, lógica de falla, etc. En este caso, la captura simplemente está enviando un mensaje a la consola, no es relevante para el método sideInput, por lo que puede manejarse más arriba en la cadena / pila de llamadas.

Uno puede deshacerse del try / catch aquí y simplemente documentar la llamada al método:

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

¡Todavía hay que manejar esa excepción más arriba en la cadena / pila de llamadas!

No debe lanzar y atrapar la misma excepción en un método, incluso creo que el bloque de captura capturará la misma excepción que está lanzando, por lo que realmente no lo está lanzando.

Si parseInttuvo éxito, entonces no es un NumberFormatException.

si el lado es menor que cero, debe lanzar un NegativeSideLengthException;

Cree una excepción personalizada / comercial denominada NegativeSideLengthException

public class NegativeSideLengthException extends Exception
{


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

}

Luego sideInputlanza 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;
}

Incluso puede (si lo desea) agregar otro bloque catch para atrapar NegativeSideLengthExceptiony no hacer que el método lo lance.

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);

Las banderas no son una buena forma de manejar las excepciones.

Las excepciones son cosas bastante pesadillas, traen más complejidades de las que resuelven.

En primer lugar, si no detecta sus excepciones, la persona que llama solo puede hacer on error resume next, es decir, después de una semana, incluso usted no sabrá qué puede arrojar su función y qué hacer con ella:

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

Básicamente, si los atrapa, debe comprender muy bien los contratos y las garantías de excepción. Eso rara vez sucede en un mundo real. Y también su código será difícil de leer.

Además, lo curioso es que si realmente tiene alguna posibilidad de manejar excepciones, necesita un lenguaje RAII real, que es algo gracioso, ya que Java y .NET se trata de excepciones ...

Repitiendo esto una vez más, pero ...:

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