try-catch w javascript… czy to nie jest dobra praktyka?

Istnieje przepis dotyczący blokowania try-catch w javascript . Podczas gdy w java lub innym języku obowiązkowa jest obsługa błędów, nie widzę, aby ktokolwiek używał ich w javascript w większym stopniu. Czy to nie jest dobra praktyka, czy po prostu nie potrzebujemy ich w javascript?

Należy unikać throwbłędów jako sposobu przekazywania warunków błędów w aplikacjach.

throwOświadczenie powinno być stosowane jedynie „Do tego nigdy nie powinno się zdarzyć, crash i spalić. Nie elegancko odzyskać w jakikolwiek sposób”

try catch jest jednak stosowany w sytuacji, gdy obiekty hosta lub skrypt ECMAScript mogą zgłaszać błędy.

Przykład:

var json
try {
    json = JSON.parse(input)
} catch (e) {
    // invalid json input, set to null
    json = null
}

Zalecenia w społeczności node.js to przekazywanie błędów w wywołaniach zwrotnych (ponieważ błędy występują tylko w przypadku operacji asynchronicznych) jako pierwszy argument

fs.readFile(uri, function (err, fileData) {
    if (err) {
        // handle
        // A. give the error to someone else
        return callback(err)
        // B. recover logic
        return recoverElegantly(err)
        // C. Crash and burn
        throw err
    }
    // success case, handle nicely
})

Istnieją również inne problemy, takie jak try / catch jest naprawdę drogi i brzydki, a po prostu nie działa z operacjami asynchronicznymi.

Ponieważ operacje synchroniczne nie powinny generować błędów i nie działają z operacjami asynchronicznymi, nikt nie używa try catch, z wyjątkiem błędów zgłaszanych przez obiekty hosta lub skrypt ECMAScript

Try / catch w Javascript nie jest tak kuloodporny jak w innych językach z powodu asynchronicznej natury Javascript. Rozważ ten fragment:

try {
    setTimeout(function() {
        do_something_that_throws();
    }, 1000);
}
catch (e) {
    alert("You won't see this!");
}

Problem polega na tym, że przepływ sterowania opuszcza tryblok przed do_something_that_throws()wykonaniem, więc błąd zgłoszony w wywołaniu zwrotnym nigdy nie zostaje wyłapany.

Dlatego w wielu przypadkach try / catch jest w zasadzie nieodpowiednie i nie zawsze jest oczywiste, czy coś wykonuje kod asynchronicznie, czy nie. Na szczęście javascript ze swoistym idiomem jednowątkowym asynchronicznym zwrotnym i obsługa faktycznych zamknięć stanowi elegancką alternatywę: obsługę błędów w stylu kontynuacji przejścia. Wystarczy przekazać właściwą odpowiedź na każdy błąd jako funkcję, np .:

setTimeout(function () {
    do_something_that_calls_err(function(err) {
        alert("Something went wrong, namely this: " + err);
    }),
    1000);

Wiele z tych odpowiedzi jest nieco starych i nie uwzględnia nowych funkcji ES7 asynci await.

Używając async/ awaitmożesz teraz uzyskać asynchroniczny przepływ sterowania, jak chcesz:

async function email(address) {
  try {
    // Do something asynchronous that may throw...
    await sendEmail({ to: address, from: '[email protected]`, subject: 'Hello' })
  } catch(err) {
    if (err instanceof SomeCustomError) {
      elegantlyHandleError(err)
    } else {
      throw err
    } 
  }
})

Dowiedz się więcej o async/ awaittutaj . Możesz użyć async/ awaitteraz używając babel .

try-catch w javascript jest tak samo ważny i użyteczny jak w każdym innym języku, który je implementuje. Jest jeden główny powód, dla którego nie jest tak często używany w javascript, jak w innych językach. Z tego samego powodu javascript jest postrzegany jako brzydki język skryptowy, z tego samego powodu, dla którego ludzie myślą, że programiści javascript nie są prawdziwymi programistami:

• JavaScript jest niezwykle dostępnym i wszechobecnym językiem

Sam fakt, że tak wiele osób jest narażonych na javascript (z powodu jedynego obsługiwanego języka przez przeglądarki) oznacza, że ​​masz dużo nieprofesjonalnego kodu. Oczywiście istnieje również wiele drobnych powodów:

• niektóre rzeczy w javascript są asynchroniczne i dlatego nie są w catchstanie (rzeczy asynchroniczne)
• wiele mówi się o tym, jak try-catch ma ogromny wpływ na wydajność. Ma trochę wyższą wydajność , ale dla większości kodów jest tego warte.
• javascript został (niestety) zaimplementowany w sposób, który często dyskretnie ignoruje błędy (na przykład automatycznie zmienia ciągi znaków na liczby)

Niezależnie od tego, try-catch powinny być stosowane, ale oczywiście trzeba nauczyć się je właściwie wykorzystać - jak wszystko w programowaniu.

Uważam, że wiele powodów, które try..catchsą rzadkie w JavaScript, to fakt, że język ma dość wysoką tolerancję na błędy. Zdecydowaną większość sytuacji można rozwiązać za pomocą kontroli kodu, dobrych wartości domyślnych i zdarzeń asynchronicznych. W niektórych przypadkach po prostu użycie wzorca zapobiegnie problemom:

function Foo() {
    //this may or may not be called as a constructor!!
    //could accidentally overwrite properties on window
}

function Bar() {
    if (!(this instanceof Bar)) {
        return new Bar();
    }
    //this will only work on Bar objects, and wont impact window
}

Niektóre z głównych problemów w innych językach, które powodują wyjątki, po prostu nie istnieją w JS. Rzutowanie typu nie jest potrzebne przez większość czasu. Zamiast tego preferowaną metodą jest zazwyczaj sprawdzenie funkcji (wymuszenie określonego interfejsu):

function doFoo(arg) {
    if (arg.foo) {
        arg.foo();
    } else {
        Bar.prototype.foo.call(arg);
    }
}

Wraz z dodaniem async/ awaitdo języka try..catchstaje się coraz bardziej powszechne. Obiecuje, że jest formą asynchroniczną try..catch, dlatego warto oczekiwać, że:

doSomething().then(
  doSomethingWithResult,
  doSomethingWithError
)

zamiast tego należy zapisać jako:

try {
  const result = await doSomething()
  doSomethingWithResult(result)
} catch (e) {
  doSomethingWithError(e)
}

Być może kolejnym powodem, dla którego try / catch nie jest zbyt często używany w Javascript, jest to, że konstrukcja nie była dostępna w pierwszych wersjach Javascript ... została dodana później.

W rezultacie niektóre starsze przeglądarki nie obsługują tego. (W rzeczywistości może powodować błąd analizatora składni / składni w niektórych starszych przeglądarkach, co jest trudniejsze do „zaprogramowania w obronie” przed większością innych rodzajów błędów).

Co ważniejsze, ponieważ początkowo nie był dostępny, wbudowane funkcje JavaScript, które zostały początkowo wydane (co w wielu językach można by nazwać funkcjami „bibliotecznymi”), nie korzystają z niego. (Nie działa zbyt dobrze, aby „złapać” błąd z someobject.somefunction (), jeśli nie „wyrzuca”, ale zamiast tego zwraca po prostu „null”, gdy napotka problem.)

Jeszcze innym możliwym powodem jest to, że mechanizm try / catch początkowo nie wydawał się potrzebny (i nadal nie wydaje się tak przydatny). Jest to naprawdę potrzebne tylko wtedy, gdy połączenia są rutynowo zagnieżdżane na kilku poziomach; samo zwrócenie jakiegoś ERRNO działałoby dobrze w przypadku połączeń bezpośrednich (chociaż aby było naprawdę przydatne, gdy tylko jest dostępne, najlepszą praktyką w większości języków jest używanie go wszędzie, a nie tylko w przypadku głęboko zagnieżdżonych połączeń). Ponieważ początkowo oczekiwano, że logika Javascript będzie niewielka i prosta (w końcu jest to tylko dodatek do strony internetowej :-), wywołania funkcji nie były głęboko zagnieżdżone, więc mechanizm try / catch nie wydawał się konieczny.

Uważam, że nie są tak często używane, ponieważ zgłaszanie wyjątków w kodzie klienta JavaScript utrudnia debugowanie strony.

Zamiast rzucać wyjątki, generalnie wolę pokazywać wszystkie alerty, (tj. alert("Error, invalid...");)

Może to zabrzmieć dziwnie, ale po stronie klienta występują błędy JavaScript, jeśli klient korzysta ze strony, którą zbudowałeś, a strona zgłasza wyjątek, chyba że klient jest specjalistą od kodowania, nie ma mowy, by kiedykolwiek mógł powiedzieć o co ci chodzi.

Zadzwoni tylko do Ciebie, mówiąc: „Hej, strona X nie działa!”, A następnie od Ciebie zależy, czy uda Ci się znaleźć to, co poszło nie tak i gdzie w kodzie.

Używając zamiast tego pola alertu, bardziej prawdopodobne jest, że zadzwoni i powie coś w stylu: „Hej, kiedy kliknę przycisk A strony X, wyświetli się pole z napisem ...” , zaufaj mi, łatwiej będzie znaleźć błąd.