Właściwe wykorzystanie błędów


155

Używam TypeScript do rozsądnie dużego projektu i zastanawiam się, jaki jest standard używania Errors. Na przykład, powiedzmy, że podaję wyjątek indeksu poza granicami w Javie:

throw new IndexOutOfBoundsException();

Czy odpowiednikiem instrukcji w TypeScript byłoby:

throw new Error("Index Out of Bounds");

Jakie inne sposoby mogę to osiągnąć? Jaki jest przyjęty standard?

Odpowiedzi:


167

Ktoś zamieścił ten link do MDN w komentarzu i myślę, że był bardzo pomocny . Opisuje bardzo dokładnie takie rzeczy, jak ErrorTypes.

EvalError --- Tworzy instancję reprezentującą błąd dotyczący globalnej funkcji eval ().

InternalError --- Tworzy instancję reprezentującą błąd, który pojawia się, gdy zostanie zgłoszony błąd wewnętrzny w silniku JavaScript. Np. „Za dużo rekursji”.

RangeError --- Tworzy instancję reprezentującą błąd występujący, gdy zmienna numeryczna lub parametr jest poza swoim prawidłowym zakresem.

ReferenceError --- Tworzy instancję reprezentującą błąd występujący podczas usuwania odwołania do nieprawidłowego odwołania.

SyntaxError --- Tworzy instancję reprezentującą błąd składniowy, który występuje podczas analizowania kodu w eval ().

TypeError --- Tworzy instancję reprezentującą błąd, który występuje, gdy zmienna lub parametr nie jest prawidłowego typu.

URIError --- Tworzy instancję reprezentującą błąd występujący, gdy do metody encodeURI () lub decodeURI () przekazano nieprawidłowe parametry.


Wydaje się, że brakuje bardziej ogólnego typu nieprawidłowego argumentu . Nie wszystkie nieprawidłowe argumenty podlegają RangeError. Należy zdefiniować typy niestandardowe, czy po prostu throw new Error("<message>");?
anddero

58

Konwencja poza zakresem w JavaScript używa RangeError. Aby sprawdzić typ, użyj if / else +, instanceofzaczynając od najbardziej specyficznego do najbardziej ogólnego

try {
    throw new RangeError();
}
catch (e){
    if(e instanceof RangeError){
        console.log('out of range');
    }
}

2
A co z ogólnym błędem? I / lub gdzie jest lista wbudowanych klas błędów JS?
pitosalas

7
W sieci Mozilla Developer Network znajduje się lista typów błędów JavaScript i inne informacje: developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/ ...
Christian Davén

6
@basarat Myślę, że powinieneś dodać else { throw; }tutaj
knocte

44

Proste rozwiązanie do emitowania i wyświetlania wiadomości według wyjątku.

try {
  throw new TypeError("Error message");
}
catch (e){
  console.log((<Error>e).message);//conversion to Error type
}

Uwaga

Powyższe nie jest rozwiązaniem, jeśli nie wiemy, jaki rodzaj błędu można wyemitować z bloku. W takich przypadkach należy stosować osłony typu i odpowiednio obchodzić się z błędami - spójrz na odpowiedź @Moriarty.


Dzięki za wskaźnik do jawnej konwersji typu. Nie znalazłem tych informacji w maszynopisach i dowiedziałem się czegoś dzisiaj.
JackLeEmmerdeur,

czy wiesz jaki jest cel dodania <Error>? e.message działa dla mnie dobrze.
sbattou

1
@sbattou jedynym celem <Error>jest poinformowanie kompilatora TS, że ejest to typ <Error>, abyś miał (1) intelisense i (2) lepsze sprawdzanie typów. Pamiętaj jednak, że każdy rzut w ogóle nie przekłada się na JS i jest czysto syntaktycznym cukrem.
Didii,

25

Nie zapomnij o instrukcjach switch:

  • Zapewnij obsługę z default.
  • instanceof może się równać w superklasie.
  • ES6 constructorbędzie pasować dokładnie w tej klasie.
  • Łatwiejsze do odczytania.

function handleError() {
    try {
        throw new RangeError();
    }
    catch (e) {
        switch (e.constructor) {
            case Error:      return console.log('generic');
            case RangeError: return console.log('range');
            default:         return console.log('unknown');
        }
    }
}

handleError();


3
To jest świetne; wydaje się solidniejszy i bardziej przejrzysty niż inne odpowiedzi.
Victor Zamanian
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.