В настоящее время я работаю над приложением node.js, и у меня обычная проблема с асинхронным кодом.
Я реализую сервисный сервер поверх HTTP-модуля Node.
Этот сервер поддерживает маршруты (express like). Например, у меня есть код, который выглядит так:
server.any("/someRoute",function(req,resp){
resp.end("this text is sent to clients via http")
});
Сервер должен быть в состоянии противостоять сбоям, я не хочу, чтобы весь сервер вышел из строя, когда есть проблема в функции, переданной кому-либо. Проблема возникает, когда я пишу код, который выглядит так:
server.any("/someRoute",function(req,resp){
setTimeout(function(){
throw new Error("This won't get caught");
},100);
});
Я не понимаю, как я могу поймать ошибку здесь. Я не хочу крашить сервер из-за одного сбоя на стороне сервера, вместо этого я хочу обслуживать 500.
Единственные решения, которые я смог придумать, на самом деле не выразительны. Я придумал использовать только process.on("uncaughtException",callback)
и аналогичный код с использованием узла 0.8 Domains
(что является частичным решением, но домены в настоящее время глючат, и это все еще не очень выразительно, так как в конечном итоге мне приходится создавать домен для каждого дескриптора).
Чего я хотел бы добиться, так это привязать throw
действий из функции к области видимости, идеальное решение — это что-то вроде привязки всех выброшенных ошибок из функции к конкретной функции-обработчику.
Это возможно? Как лучше всего обрабатывать ошибки в этом случае?
Я хотел бы подчеркнуть, что он должен иметь возможность продолжать обслуживать запросы после плохих запросов, и перезапуск сервера при каждом запросе или создание доменов для каждого обработчика и перехват их неперехваченных исключений кажется мне плохой идеей. Кроме того, я слышал, что обещания могут помочь мне (что-то о throw
в обещаниях), могут ли обещания помочь мне в этой ситуации?
throw
ing из асинхронного кода — дурной тон, и, например, там, где ничего не поделаешь (возможно,JSON.parse
терпит неудачу и т. д.), событиеuncaughtException
— это ваш билет к сохранению вашего приложения (хотя для библиотеки, безусловно, было бы лучшеcatch
внутри собственного кода). - person Michelle Tilley   schedule 13.01.2013