Zgłaszanie i wyławianie wyjątków w tej samej funkcji / metodzie

Napisałem funkcję, która prosi użytkownika o wprowadzenie danych, dopóki użytkownik nie wprowadzi dodatniej liczby całkowitej (liczby naturalnej). Ktoś powiedział, że nie powinienem wyrzucać i wychwytywać wyjątków w mojej funkcji i pozwolić, aby wywołujący moją funkcję je obsługiwał.

Zastanawiam się, co sądzą o tym inni programiści. Prawdopodobnie niewłaściwie wykorzystuję wyjątki w funkcji. Oto kod w Javie:

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

Interesują mnie dwie rzeczy:

1. Czy powinienem pozwolić rozmówcy martwić się o wyjątki? Istotą tej funkcji jest to, że dręczy użytkownika, dopóki użytkownik nie wprowadzi liczby naturalnej. Czy punkt funkcji jest zły? Nie mówię o interfejsie użytkownika (użytkownik nie jest w stanie wydostać się z pętli bez odpowiedniego wejścia), ale o zapętlonym wejściu z obsługiwanymi wyjątkami.
2. Czy powiedziałbyś, że instrukcja throw (w tym przypadku) jest niewłaściwym wykorzystaniem wyjątków? Mogę łatwo utworzyć flagę do sprawdzania poprawności numeru i wypisać komunikat ostrzegawczy na podstawie tej flagi. Ale to dodałoby więcej linii do kodu i myślę, że jest on w pełni czytelny.

Rzecz w tym, że często piszę osobną funkcję wejściową. Jeśli użytkownik musi wprowadzić liczbę wiele razy, tworzę osobną funkcję wprowadzania, która obsługuje wszystkie wyjątki i ograniczenia formatowania.

Wyjątkiem jest to, że pozwala metodzie powiedzieć dzwoniącemu, który wszedł w stan, w którym nie mógł normalnie kontynuować, bez zmuszania użytkownika do osadzenia kodu błędu w wartości zwracanej.

W twoim przypadku twoja metoda dokładnie wie, co robić, gdy wartość wejściowa nie jest większa niż 0. Jedynym powodem, dla którego zapisujesz tutaj wiersze, jest to, że zdarza się, że generujesz ten sam wyjątek, jaki byś otrzymał, gdyby dane wejściowe nie były liczbą. Jednak wyjątek, który zgłaszasz, nie pokazuje poprawnie, dlaczego twój kod nie lubi danych wejściowych. Gdyby ktoś inny przyszedł i zobaczył ten kod, musiałby poświęcić dodatkowy czas na sprawdzenie, jak dokładnie działa.

To złe użycie wyjątków. Na początek liczba dodatnia nie jest wyjątkiem formatu.

Po co w ogóle korzystać z wyjątków? Jeśli wiesz, które dane wejściowe są niedozwolone, po prostu nie wychodź z pętli, dopóki nie uzyskasz prawidłowych danych wejściowych od użytkownika, coś takiego:

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

Łap wyjątki tylko wtedy, gdy zamierzasz zrobić coś, co jest istotne dla bieżącego wywołania metody; tj. czyszczenie, logika awarii itp. W tym przypadku catch po prostu wysyła komunikat do konsoli, nie ma znaczenia dla metody sideInput, dlatego może być obsługiwany dalej w łańcuchu połączeń / stosie.

Tutaj możesz pozbyć się try / catch i po prostu udokumentować wywołanie metody:

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

Nadal trzeba poradzić sobie z tym wyjątkiem w łańcuchu połączeń / stosie!

Nie powinieneś rzucać i wychwytywać tego samego wyjątku w metodzie, nawet myślę, że blok przechwytuje ten sam wyjątek, który rzucasz, więc tak naprawdę go nie rzucasz.

Jeśli się parseIntudało, to nie jest NumberFormatException.

jeśli strona jest mniejsza niż zero, powinieneś rzucić NegativeSideLengthException;

Utwórz niestandardowy / biznesowy wyjątek o nazwie NegativeSideLengthException

public class NegativeSideLengthException extends Exception
{


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

}

Następnie sideInputzgłasza 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;
}

Możesz nawet (jeśli chcesz) dodać kolejny blok przechwytywania, aby złapać NegativeSideLengthExceptioni nie ma metody rzucić go.

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

Flagi nie są dobrym sposobem radzenia sobie z wyjątkami.

Wyjątki to koszmarne rzeczy, przynoszą więcej złożoności niż rozwiązują.

Po pierwsze, jeśli nie złapiesz wyjątków, dzwoniący może tylko to zrobić on error resume next, to znaczy po tygodniu nawet ty nie będziesz wiedział, co twoja funkcja może rzucić i co z tym zrobić:

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

Zasadniczo, jeśli je złapiesz, musisz bardzo dobrze rozumieć umowy i gwarancje wyjątków. To rzadko zdarza się w prawdziwym świecie. A także twój kod będzie trudny do odczytania.

Zabawne jest również to, że jeśli naprawdę masz szansę poradzić sobie z wyjątkami, potrzebujesz prawdziwego języka RAII, co jest dość zabawne, ponieważ Java i .NET to wyjątki ...

Powtarzam to jeszcze raz, ale ...:

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