Javascript/Typescript의 오류 처리: 사용자 정의 예외 및 결과

API를 호출하거나 사용자가 입력한 데이터의 유효성을 검사하는 등의 작업은 개발에서 매우 일반적이며 올바른 결과를 제공하거나 실패할 수 있는 함수의 예입니다. 일반적으로 자바스크립트(및 기타 언어)로 제어하기 위해 간단한 예외를 사용하고 생성합니다.

우리가 개발 중인 애플리케이션이나 프로그램에 발생할 수 있는 오류를 제어하는 ​​가장 간단한 방법인 것 같습니다. 그러나 프로젝트와 팀이 성장함에 따라 우리에게 더 많은 것을 요구하는 시나리오가 나타나기 시작합니다. 예를 들어, 대규모 팀에서는 기능이 실패할 수 있는지 여부를 명시적으로 표시하여 동료가 이러한 오류를 예측하고 관리할 수 있도록 하면 많은 도움이 됩니다.

작업이 가질 수 있는 '오류' 유형을 명시적으로 지정하면 개발이 훨씬 쉬워질 뿐만 아니라 또한 비즈니스 규칙에 대한 문서로도 사용됩니다.

자바스크립트에는 이를 달성하기 위한 몇 가지 기술이 있습니다. 이론을 뛰어넘어 실제 사례를 살펴보겠습니다. 호텔 예약 앱에서 사용자는 객실을 예약하고 코드를 받은 다음 요금을 지불해야 합니다. 결제 시 API는 현재 다음과 같은 3가지 "오류" 시나리오를 표시할 수 있습니다.

El código de reserva no existe.
El pago es rechazado.
El código de reserva ya no es válido.

사용자를 위한 애플리케이션을 만들 때 위 두 가지 경우 외에 추가로 고려해야 할 사항은 다음과 같습니다.

No hay conexión a internet. (o el servicio no esta disponible)

이 함수는 애플리케이션의 다양한 구성 요소에서 호출할 수 있으며, 실패할 경우 사용자에게 오류가 표시되어야 합니다.

이 예를 염두에 두고 이를 처리하는 방법에 대한 몇 가지 가능성을 검토해 보겠습니다

사용자 정의 오류

예외는 많은 언어에서 흔히 발생하며 JavaScript에는 사전 정의된 일부 예외(예: SyntaxError)가 포함되어 있습니다. 발생할 수 있는 오류를 처리할 때는 구체적으로 설명하고 개인화하는 것이 좋습니다.

JS에서 예외를 생성하려면 예약어 throw를 사용하고 그 뒤에 원하는 것을 입력하면 됩니다(그렇게 읽는다면).

function makeError() {
  throw "Error string"
}

Js는 그런 의미에서 매우 관대하지만, js에 포함된 Error 클래스의 자손이 아닌 것을 던지는 것은 나쁜 습관으로 간주됩니다.

class MyError extends Error {

  constructor(message) {
    super(message);
    this.name = "MyError";
  }
}


function makeError() {
  throw MyError("")
}

보시다시피 오류 클래스에는 예외를 생성하는 이유를 더 자세히 설명할 수 있는 속성이 함께 제공됩니다(원하는 속성을 추가할 수 있음).

예를 들어 제시한 문제로 돌아갑니다. 사용자 정의 오류를 적용함으로써 각 시나리오에서 수행할 작업을 제어할 수 있습니다.

El código de reserva no existe.
El pago es rechazado.
El código de reserva ya no es válido.

이를 통해 우리는 흐름을 다양한 방식으로 라우팅할 수 있을 뿐만 아니라 시스템의 내부 오류(예: payReservation 내에서 사용하는 일부 내부 종속성의 오류)와 비즈니스 규칙을 나타내는 오류를 구별할 수도 있습니다. .

이것은 매우 좋은 옵션이며 각 경우에 따라 흐름을 제어하려는 우리의 목표를 충족하며 누군가 기능을 보면 실패할 수 있는 이유를 알 수 있습니다. 이를 통해 우리는 이미 많은 것을 얻었지만 이 접근 방식에는 고려해야 할 몇 가지 사항이 있습니다.

캐치 내에서 제어되지 않는 기능의 예외는 "상위 수준"으로 이동합니다. 예를 들어, B를 호출하는 A 함수가 있는 경우 이 함수는 C를 호출하고 C는 예외를 발생시킵니다. . 제어됨 이는 B로 이동하며, B가 제어하지 않으면 다음까지 계속됩니다. A 등 이는 귀하의 경우에 따라 좋은 소식일 수 있습니다. 비즈니스 규칙에 따라 오류 가능성을 선언하는 것은 지루한 일이 될 수 있습니다. 왜냐하면 가능한 예외가 있는지 모든 기능을 검토해야 하기 때문입니다.

또 하나 고려해야 할 점은 개발자 만료가 오늘날 매우 중요하다는 점입니다. JsDoc과 같은 도구를 사용하면 메소드에 예외가 있을 수 있음을 추가하는 방법을 설명할 수 있지만 편집기는 이를 인식하지 못합니다. 반면에 Typescript는 함수를 작성하거나 호출할 때 이러한 예외를 인식하지 못합니다.

[] **성능:* 예외 발생 및 처리는 성능에 (최소) 영향을 미칩니다(break 사용과 유사). 앱과 같은 환경에서는 영향이 거의 0이지만.

결과(또는 둘 중 하나) 값으로 오류 캡슐화

이전 사례를 살펴보면 우리가 생성한 예외는 "복구할 수 없는" 오류로 인한 것이 아니라 비즈니스 규칙의 일부입니다. 예외가 일반화되면 더 이상 예외적인 경우가 아니며 이를 위해 설계되었습니다. 예외를 발생시키는 대신 다음과 같이 "성공" 및 "오류" 상태를 단일 개체에 캡슐화할 수 있습니다.

No hay conexión a internet. (o el servicio no esta disponible)

typescript(또는 jsdoc를 사용하는 경우 d.ts)를 사용하면 다음과 같이 유형을 정의할 수 있습니다.

function makeError() {
  throw "Error string"
}

이를 예시에 적용해 보겠습니다. 이제 payReservation 함수가 예외 대신 이 객체를 반환하는 경우 JSDoc 또는 Typescript를 사용하여 어떤 유형의 결과를 얻을 수 있는지 지정할 수 있습니다(이제부터는 단순화를 위해 예제를 TypeScript에 넣겠습니다).
이를 통해 팀은 함수가 어떤 오류를 반환할 수 있는지 미리 알 수 있습니다.

class MyError extends Error {

  constructor(message) {
    super(message);
    this.name = "MyError";
  }
}


function makeError() {
  throw MyError("")
}

이를 적용함으로써 예외가 있는 접근 방식의 장점을 얻을 수 있으며, 개발 시 편집자는 발생할 수 있는 다양한 "오류" 사례에 대한 정보를 표시합니다.

사실 이러한 유형의 개념은 오랫동안 프로그래밍에 존재해 왔으며 많은 기능적 언어에서는 예외가 없으며 오류에 대해 이러한 유형의 데이터를 사용합니다. 오늘날 많은 언어에서 이를 구현합니다. 예를 들어 Rust와 Dart에서는 Result 클래스가 기본적으로 존재하며 Kotlin의 Arrow 라이브러리도 이를 추가합니다.

결과를 사용하고 구현하는 방법에 대한 특정 표준이 있으므로 새로운 개발자가 코드를 더 쉽게 이해할 수 있도록 이러한 규칙을 사용할 수 있습니다.

결과는 성공 또는 오류 상태만 나타낼 수 있으며(동시에 둘 다일 수 없음) 예외를 발생시키지 않고 두 상태 모두에 대해 작업할 수 있습니다.

El código de reserva no existe.
El pago es rechazado.
El código de reserva ya no es válido.

예제는 클래스를 사용하지만 꼭 필요한 것은 아닙니다. 더 간단한 구현도 있습니다. 필요할 수 있다고 생각되는 프로젝트에 보통 가져가는 것이 있습니다. 보고 싶을 경우를 대비해 링크를 남겨둡니다. 사용하세요.

이대로 놔두면 이전에 만든 객체에 비해 별로 얻을 것이 없습니다. 그렇기 때문에 일반적으로 더 많은 메소드를 구현한다는 것을 알아두면 좋습니다

예를 들어 오류 발생 시 기본값을 반환하는 getOrElse 메소드입니다.

No hay conexión a internet. (o el servicio no esta disponible)

성공/실패 흐름을 기능적으로 처리하기 위해 접습니다.

function makeError() {
  throw "Error string"
}

둘 중 하나를 사용하여 오류 처리에 대한 정보를 찾을 수도 있습니다. 결과는 더 큰 맥락을 가진 둘 중 하나이며, 오른쪽(오른쪽)과 왼쪽(왼쪽) 값을 갖습니다. 영어에서 right는 어떤 것이 옳다는 것을 의미하는 데에도 사용되며 일반적으로 오류가 왼쪽에 있는 동안 올바른 값을 갖지만 반드시 그런 것은 아니며 대신 결과가 더 명확합니다. 여기서 이것은 올바른 값이고 오류입니다.

이를 예시에 적용하면 payReservation은 다음과 같습니다.

class MyError extends Error {

  constructor(message) {
    super(message);
    this.name = "MyError";
  }
}


function makeError() {
  throw MyError("")
}

[*] 오류에 대한 기본 데이터 유형을 설정하는 것이 좋은 방법입니다. 예제에서는 문자열을 사용하지만 이상적으로는 더 많은 데이터를 추가할 수 있는 명명된 객체와 같이 더 정의된 형식을 갖는 것이 좋습니다. 예를 들어, 여기에서 이에 대한 예를 볼 수 있습니다

얼핏 보면 클래스를 추가하는 것이 다른 어떤 것보다 과도한 엔지니어링처럼 보일 수 있습니다. 그러나 Result는 널리 사용되는 개념이므로 규칙을 유지하면 팀이 이를 더 빨리 파악하는 데 도움이 되며 오류 처리를 강화하는 효과적인 방법입니다.

이 옵션을 사용하면 함수에 발생할 수 있는 "오류"가 무엇인지 명시적으로 설명하고, 오류 유형에 따라 애플리케이션의 흐름을 제어할 수 있으며, 함수를 호출하는 동안 편집기에서 도움을 받고 마지막으로 오류에 대한 예외를 남겨둘 수 있습니다. 시스템의 사례입니다.

이러한 장점에도 불구하고 구현하기 전에 몇 가지 사항을 고려해야 합니다. 이 섹션의 시작 부분에서 언급했듯이 Result는 많은 언어에서 기본이지만 JS에서는 그렇지 않습니다. 따라서 이를 구현함으로써 추가 추상화를 추가합니다. 고려해야 할 또 다른 점은 우리가 처한 시나리오입니다. 모든 애플리케이션에 그렇게 많은 제어가 필요한 것은 아닙니다(예를 들어 광고 캠페인의 랜딩 페이지에서는 결과 구현의 요점을 알 수 없습니다). 잠재력을 모두 활용할 수 있을지, 아니면 무게만 더 늘어날 뿐인지 평가해 볼 가치가 있습니다.

---

간단히 말하면, 오류를 처리하면 코드 품질이 향상될 뿐만 아니라 예측 가능하고 잘 문서화된 워크플로를 제공하여 팀 협업도 향상됩니다. 결과 및 사용자 정의 예외는 잘 사용하면 유지 관리가 용이하고 강력한 코드를 만드는 데 도움이 되는 도구입니다.

TS의 추가 기능

TypeScript에서는 모든 오류 사례를 처리하기 위해 Result의 추가적인 이점을 얻을 수 있습니다.

El código de reserva no existe.
El pago es rechazado.
El código de reserva ya no es válido.

typeCheck 함수는 if/else if 내에서 e의 가능한 모든 값이 확인되었는지 검증하는 것을 목표로 합니다.
이번 레포에서는 좀 더 자세한 내용을 남겨드립니다.

---

위 내용은 Javascript/Typescript의 오류 처리: 사용자 정의 예외 및 결과의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!