Node.js + Express.js 응용 프로그램에 대한 오류 처리 원칙?

Node.js + Express.js 응용 프로그램에 대한 오류 처리 원칙?

Node.js+Express.js 응용 프로그램에서 오류 보고/처리가 다른 프레임워크와 다르게 수행되는 것 같습니다.다음과 같이 작동하는 것으로 알고 있는데 맞나요?

A)콜백 함수에 대한 매개 변수로 오류를 수신하여 오류를 탐지합니다.예를 들어,

doSomethingAndRunCallback(function(err) { 
    if(err) { … }
});

B)다음(err)을 호출하여 미들웨어의 오류를 보고합니다.예:

handleRequest(req, res, next) {
    // An error occurs…
    next(err);
}

C)오류를 던져 ROOTES의 오류를 보고합니다.예:

app.get('/home', function(req, res) {
    // An error occurs
    throw err;
});

D)app.error()를 통해 오류 처리기를 구성하여 오류를 처리하거나 일반 Connect 오류 처리기를 사용합니다.예:

app.error(function(err, req, res, next) {
    console.error(err);
    res.send('Fail Whale, yo.');
});

Node.js+Express.js 응용 프로그램의 모든 오류 처리/보고의 기본이 되는 네 가지 원칙입니까?

Node.js의 오류 처리는 일반적으로 A) 형식입니다.대부분의 콜백은 첫 번째 인수로 오류 개체를 반환합니다.null.

Express.js는 미들웨어를 사용하고 미들웨어 구문은 B)와 E)를 사용합니다.

C) 저한테 물어보시면 나쁜 연습입니다.

app.get('/home', function(req, res) {
    // An error occurs
    throw err;
});

위의 내용을 다음과 같이 쉽게 다시 작성할 수 있습니다.

app.get('/home', function(req, res, next) {
    // An error occurs
    next(err);
});

미들웨어 구문은 a에서 유효합니다.get부탁한다.

D)의 경우

(07:26:37 PM) tjholowaychuk: app.error는 3.x에서 제거됩니다.

TJ는 방금 확인했습니다.app.errorE에게 유리하게 감가상각됩니다.

E)

app.use(function(err, req, res, next) {
  // Only handle `next(err)` calls
});

길이가 4(4개 인수)인 미들웨어는 오류 미들웨어로 간주됩니다.전화할때next(err)connect goes 및 호출 오류 기반 미들웨어.

Joyent의 사람들은 이에 대해 정말 통찰력 있는 모범 사례 문서를 발표했습니다.Node.js 개발자라면 반드시 읽어야 할 문서입니다.

왜 첫 번째 매개변수죠?

Node.js의 비동기적 특성 때문에, 첫 번째 매개변수-as-err 패턴은 userland Node.js 오류 처리에 대한 규칙으로 잘 자리 잡았습니다.그 이유는 다음과 같습니다.

try {
    setTimeout(function() {
        throw 'something broke' //Some random error
    }, 5)
}
catch(e) {
   //Will never get caught
}

따라서 콜백의 첫 번째 인수를 수행하는 것이 단순히 오류를 던지는 것 외에 비동기적으로 오류를 전달할 수 있는 거의 유일한 합리적인 방법입니다.

그렇게 하는 것은 결과를 낳을 것입니다.unhandled exception이는 단순히 들리는 것처럼, 애플리케이션이 혼란스러운 상태에서 벗어나도록 아무 조치도 취하지 않았다는 것을 의미합니다.

예외들, 왜 존재하는 것일까요?

그러나 사실상 Node.js의 모든 부분이 이벤트 에미터이고 예외를 던지는 것은 모든 이벤트처럼 처리될 수 있는 낮은 수준의 이벤트입니다.

//This won't immediately crash if connection fails
var socket = require("net").createConnection(5000);
socket.on("error", function(err) {
    console.error("calm down...", err)
});

이는 모든 오류를 파악하기 위해 극단적으로 사용해서는 안 되며 절대 충돌하지 않도록 매우 노력하는 애플리케이션을 만들 수 있습니다.이는 거의 모든 사용 사례에서 끔찍한 아이디어입니다. 애플리케이션 상태에서 무슨 일이 일어나고 있는지 전혀 알지 못한 채 개발자에게 남겨질 것이고, 메인을 트라이캐치로 래핑하는 것과 유사하기 때문입니다.

도메인 - 이벤트를 논리적으로 그룹화합니다.

도메인은 응용 프로그램을 실패하게 만드는 예외 문제를 해결하기 위해 개발자가 Express.js 응용 프로그램을 사용하고 치명적인 장애가 발생할 경우 현명하게 연결을 종료할 수 있도록 허용합니다.

ES6

ES6에서 생성기 패턴이 시도/캐치 블록에서 여전히 포착 가능한 비동기 이벤트를 생성할 수 있도록 허용함에 따라 이는 다시 변경될 것임을 언급하고 있습니다.

코아(TJ 홀로웨이척 지음, Express.js의 동일한 원작자)는 눈에 띄게 이렇게 합니다.ES6를 사용합니다.yieldsyncronous처럼 보이지만 일반적인 노드 비동기 방식으로 처리되는 블록을 만드는 statement:

app.use(function *(next) {
    try {
        yield next;
    } 
    catch (err) {
        this.status = err.status || 500;
        this.body = err.message;
        this.app.emit('error', err, this);
    }
});

app.use(function *(next) {
    throw new Error('some error');
})

이 예는 여기서 뻔뻔하게 도둑맞았습니다.

언급URL : https://stackoverflow.com/questions/7151487/error-handling-principles-for-node-js-express-js-applications