Celowe zgłaszanie wyjątków w połowach

Czy w typowym if...elsepakiecie z obsługą wyjątków coś w rodzaju poniższego przykładu jest zalecaną praktyką pozwalającą uniknąć powielania kodu?

try
{
    if (GetDataFromServer())
    {
        return ProcessData();
    }
    else
    {
        throw new Exception();
    }
catch(Exception ex)
{
    return null;
}

zamiast...

try
{
    if (GetDataFromServer())
    {
        return ProcessData();
    }
    else
    {
        return null;
    }
}
catch(Exception ex)
{
    return null;
}

Wiem, że nastąpił niewielki spadek wydajności, ale zastanawiam się, czy uważa się to za dopuszczalną praktykę. Obecnie robię to drugą metodą - szczególnie w przypadkach, w których muszę inaczej obsługiwać określone wyjątki - ale zastanawiałem się, czy pierwsza metoda jest odpowiednia dla prostych przypadków.

Microsoft odradza stosowanie obsługi wyjątków do kontroli przepływu.

Dostępny jest okrągły stół na ten temat.

Biorąc to pod uwagę, C # obsługuje to i przypuszczam, że zależy to od napotkanego warunku, czy wyjątek jest najbardziej odpowiednią odpowiedzią.

Trafienie w wydajność jest prawdopodobnie znikome, jak wyjaśniono w tej odpowiedzi .

Przejdźmy więc do wniosku, że wydajność nie stanowi problemu. Rzucasz System.Exception, aby przenieść egzekucję do catchklauzuli . BadControlFlowThatShouldBeRewrittenExceptionJednak rzucanie byłoby prawdopodobnie przesadą.

Rozwalmy to. Mamy:

• Metoda GetDataFromServer(nazwy metod powinny być PascalCase w języku C #), które mogą wyrzucić wyjątek lub zwrócić a bool.
• Jeśli wynik był true, uruchom ProcessData.
• Wróć nullinaczej.

Wygląda na to, że metoda, w której napisany jest ten kod, po prostu robi zbyt wiele rzeczy. GetDataFromServerzwracanie boolwygląda jak błąd projektowy, oczekiwałbym, że ta metoda zwróci dane otrzymywane z serwera , niektóre IEnumerable<SomeType>zawierające 0 lub więcej elementów - tj. szczęśliwa ścieżka zwraca n elementów, gdzie n> 0 , niezbyt szczęśliwy ścieżka zwraca 0 elementów, a niezadowolona ścieżka wysadza się w powietrze z nieobsługiwanym wyjątkiem, cokolwiek to jest.

To bardzo zmienia wygląd metody - znowu trudno jest stwierdzić, czy ma to sens, ponieważ oryginalny post ma tylko jeden punkt wyjścia (a zatem nie skompiluje się, ponieważ nie wszystkie ścieżki kodu zwracają wartość ), więc to tylko dzikie przypuszczenie:

try
{
    var result = GetDataFromServer();
    return ProcessData(result);
}
catch
{
    return null;
}

Tutaj możesz zobaczyć ProcessDatai zobaczyć, że iteruje iterację result, i zwraca, nulljeśli nie ma żadnego elementu w IEnumerable.

Dlaczego metoda się zwraca null? Serwer nie działa? Czy w zapytaniu jest błąd? Ciąg połączenia używa niewłaściwych danych logowania? Ilekroć GetDataFromServerwybuchnie wyjątek, którego się nie spodziewasz, połykasz go, wsuwasz pod dywan i zwracasz nullwartość. W tym przypadku zalecam wychwycenie określonych wyjątków i zapisanie wszystkiego; debugowanie będzie w ten sposób znacznie łatwiejsze.

Z ogólną catchklauzulą, która nie wychwytuje wyjątku, dość trudno jest zdiagnozować cokolwiek. Zamiast tego zrobiłbym to minimalnie:

catch(Exception e)
{
    return null;
}

Teraz możesz przynajmniej złamać i sprawdzić, eczy coś pójdzie nie tak.

TL; DR : Nie, rzucanie i wyławianie wyjątków dla kontroli przepływu nie jest dobrym pomysłem.

w twojej pierwszej odpowiedzi jest hit wydajności, który nie musi tam być.

try
{
    if (GetDataFromServer())
    {
        return ProcessData();
    }
    else
    {
        throw new Exception();
    }
catch(Exception ex)
{
    return null;
}

po wyjściu z instrukcji if, aby wejść do instrukcji Catch, gdy nie trzeba zmuszać kodu do zmiany kierunku, że tak powiem.

jeśli chcesz to return null; zrobić w instrukcji else, a nie w połowie, który jest złapany po wyrzuceniu z instrukcji else.

Prawdopodobnie nie dotyczy twojego prawdziwego kodu, ale ma zastosowanie do kodu ogólnego, który podałeś.

Normy mówią, że nie powinieneś tego robić.

Standardy mówią, że powinieneś to zrobić w ten sposób (ponownie na podstawie kodu ogólnego podanego w OP)

if (GetDataFromServer())
{
    return ProcessData();
}
else
{
    Return null
}

a ponieważ nie masz żadnych wyjątków, które łapiesz, nie powinieneś nawet próbować tutaj łapać.

chcesz zobaczyć wyjątki, gdy wystąpią, aby można było rozwiązać problem, który tworzy wyjątek.

Dlaczego nie o wiele prostsze:

if (!GetDataFromServer()) return null;
ProcessData();

Jeśli moduł obsługi wyjątków będzie istniał, powinien być w ProcessData ()