mirror of
https://github.com/goldbergyoni/nodebestpractices.git
synced 2025-10-28 03:25:55 +08:00
[Chinese-translation] asyncerrorhandling.chinese.md & centralizedhandling.chinese.md & operationalvsprogrammererror.chinese.md - add.
This commit is contained in:
jin jing
@ -35,22 +35,22 @@ getData(someParameter, function(err, result){
|
||||
});
|
||||
```
|
||||
|
||||
### 博客引用: "We have a problem with promises"
|
||||
### 博客引用: "我们使用promise有问题"
|
||||
摘自博客pouchdb.com
|
||||
|
||||
> ……And in fact, callbacks do something even more sinister: they deprive us of the stack, which is something we usually take for granted in programming languages. Writing code without a stack is a lot like driving a car without a brake pedal: you don’t realize how badly you need it, until you reach for it and it’s not there. The whole point of promises is to give us back the language fundamentals we lost when we went async: return, throw, and the stack. But you have to know how to use promises correctly in order to take advantage of them.
|
||||
> ……实际上, 回调会做一些更险恶的事情: 他们剥夺了我们的stack, 这是我们通常在编程语言中想当然的事情。编写没有堆栈的代码很像驾驶一辆没有刹车踏板的汽车: 你没有意识到你有多么需要它, 直到你伸手去找它, 而它不在那里。promise的全部目的是让我们回到我们在异步时丢失的语言基础: return，throw和stack。但你必须知道如何正确使用promise, 以便利用他们。
|
||||
|
||||
### 博客引用: "The promises method is much more compact"
|
||||
### 博客引用: "promise方法更加紧凑"
|
||||
摘自博客gosquared.com
|
||||
|
||||
> ………The promises method is much more compact, clearer and quicker to write. If an error or exception occurs within any of the ops it is handled by the single .catch() handler. Having this single place to handle all errors means you don’t need to write error checking for each stage of the work.
|
||||
> ………promise的方法更紧凑, 更清晰, 写起来更快速。如果在任何 ops 中发生错误或异常, 则由单个 .catch () 处理程序操作处理。有这个单一的地方来处理所有的错误意味着你不需要为每个阶段的工作写错误检查。
|
||||
|
||||
### 博客引用: "Promises are native ES6, can be used with generators"
|
||||
### 博客引用: "原生ES6支持promise，可以和generator一起使用"
|
||||
摘自博客StrongLoop
|
||||
|
||||
> ….Callbacks have a lousy error-handling story. Promises are better. Marry the built-in error handling in Express with promises and significantly lower the chances of an uncaught exception. Promises are native ES6, can be used with generators, and ES7 proposals like async/await through compilers like Babel
|
||||
> ….回调有一个糟糕的错误处理的报道。promise更好。将express内置的错误处理与promise结合起来, 大大降低了uncaught exception的几率。原生ES6支持promise, 通过编译器babel，它可以与generator，ES7提议的技术(比如async/await) 一起使用。
|
||||
|
||||
### Blog Quote: "All those regular flow control constructs you are used to are completely broken"
|
||||
### 博客引用: "所有那些您所习惯的常规的流量控制结构, 完全被打破"
|
||||
摘自博客Benno’s
|
||||
|
||||
> ……One of the best things about asynchronous, callback based programming is that basically all those regular flow control constructs you are used to are completely broken. However, the one I find most broken is the handling of exceptions. Javascript provides a fairly familiar try…catch construct for dealing with exceptions. The problems with exceptions is that they provide a great way of short-cutting errors up a call stack, but end up being completely useless of the error happens on a different stack…
|
||||
> ……关于基于异步、回调编程的最好的事情之一是, 基本上您所习惯的所有那些常规的流量控制结构, 是可以完全被打破。然而, 我发现最易打破的是处理例外。Javascript 提供了一个相当熟悉的尝试... 捕获处理异常的构造函数。异常的问题是, 它们提供了在一个调用堆栈上 short-cutting 错误的很好的方法, 但最终由于不同堆栈上发生的错误导致完全无用…
|
||||
|
||||
@ -64,20 +64,20 @@ app.use(function (err, req, res, next) {
|
||||
|
||||
```
|
||||
|
||||
### 博客引用: "Sometimes lower levels can’t do anything useful except propagate the error to their caller"
|
||||
From the blog Joyent, ranked 1 for the keywords “Node.JS error handling”
|
||||
### 博客引用: "有时较低的级别不能做任何有用的事情, 除非将错误传播给他们的调用者"
|
||||
摘自博客 Joyent, 对应关键字 “Node.JS error handling” 排名第一
|
||||
|
||||
> …You may end up handling the same error at several levels of the stack. This happens when lower levels can’t do anything useful except propagate the error to their caller, which propagates the error to its caller, and so on. Often, only the top-level caller knows what the appropriate response is, whether that’s to retry the operation, report an error to the user, or something else. But that doesn’t mean you should try to report all errors to a single top-level callback, because that callback itself can’t know in what context the error occurred…
|
||||
> …您可能会在stack的多个级别上处理相同的错误。当较低级别不能执行任何有用的操作时, 就会发生这种情况, 除非将错误传播给其调用方, 从而将错误传播到其调用方, 等等。通常, 只有 top-level 调用方知道适当的响应是什么, 无论是重试操作、向用户报告错误还是其他事情。但这并不意味着您应该尝试将所有错误报告给单个 top-level 回调, 因为该回调本身无法知道错误发生在什么上下文中…
|
||||
|
||||
|
||||
### Blog Quote: "Handling each err individually would result in tremendous duplication"
|
||||
From the blog JS Recipes, ranked 17 for the keywords “Node.JS error handling”
|
||||
### 博客引用: "单独处理每个错误将导致大量的重复"
|
||||
摘自博客 JS Recipes, 对应关键字 “Node.JS error handling” 排名17
|
||||
|
||||
> ……In Hackathon Starter api.js controller alone, there are over 79 occurences of error objects. Handling each err individually would result in tremendous amount of code duplication. The next best thing you can do is to delegate all error handling logic to an Express middleware…
|
||||
> ……仅仅在Hackathon 启动 api.js 控制器中, 有超过79处重复的错误对象。单独处理每个错误将导致大量的代码重复。您可以做的下一个最好的事情是将所有错误处理逻辑委派给一个express中间件…
|
||||
|
||||
|
||||
### Blog Quote: "HTTP errors have no place in your database code"
|
||||
From the blog Daily JS, ranked 14 for the keywords “Node.JS error handling”
|
||||
### 博客引用: "HTTP errors have no place in your database code"
|
||||
摘自博客 Daily JS, 对应关键字 “Node.JS error handling” 排名14
|
||||
|
||||
> ……You should set useful properties in error objects, but use such properties consistently. And, don’t cross the streams: HTTP errors have no place in your database code. Or for browser developers, Ajax errors have a place in code that talks to the server, but not code that processes Mustache templates…
|
||||
> ……您应该在 error 对象中设置有用的属性, 但使用此类属性时应保持一致。而且, 不要越过流: HTTP 错误在您的数据库代码中没有一席之地。或者对于浏览器开发人员来说, Ajax 错误在与服务器对话的代码中有一席之地, 而不是处理Mustache模板的代码…
|
||||
|
||||
|
||||
@ -27,25 +27,25 @@ throw new appError(errorManagement.commonErrors.InvalidInput, "Describe here wha
|
||||
```
|
||||
|
||||
### 博客引用: "程序型错误是程序中的 bug"
|
||||
摘自博客 Joyent, 对于关键字“Node.JS error handling”排名第一
|
||||
摘自博客 Joyent, 对于关键字“Node.JS error handling”排名第一
|
||||
|
||||
> …从程序型错误中恢复的最好方法是立即崩溃。您应该使用restarter运行程序, 以便在发生崩溃时自动重新启动程序。在一个使用了restarter的地方, 在面对一个瞬态程序型错误, 崩溃是最快的方式来恢复可靠的服务…
|
||||
|
||||
### 博客引用: "No safe way to leave without creating some undefined brittle state"
|
||||
摘自Node.JS官方文档
|
||||
### 博客引用: "不伴随着创建一些未定义的脆性状态，没有安全的方式可以离开"
|
||||
摘自Node.JS官方文档
|
||||
|
||||
> …By the very nature of how throw works in JavaScript, there is almost never any way to safely “pick up where you left off”, without leaking references, or creating some other sort of undefined brittle state. The safest way to respond to a thrown error is to shut down the process. Of course, in a normal web server, you might have many connections open, and it is not reasonable to abruptly shut those down because an error was triggered by someone else. The better approach is to send an error response to the request that triggered the error, while letting the others finish in their normal time, and stop listening for new requests in that worker.
|
||||
> …在 JavaScript 中, throw的工作性质, 没有泄漏引用, 或者创建一些其他类型的未定义的脆性状态，几乎没有任何方法可以安全地 "在你离开的地方重新捡起"。对引发的错误进行响应的最安全方法是关闭进程。当然, 在普通的 web 服务器中, 您可能会打开许多连接, 并且由于其他人触发了错误而突然关闭这些连接是不合理的。更好的方法是向触发错误的请求发送错误响应, 同时让其他人在正常时间内完成, 并停止侦听该工作人员中的新请求。
|
||||
|
||||
|
||||
### Blog Quote: "Otherwise you risk the state of your application"
|
||||
From the blog debugable.com, ranked 3 for the keywords “Node.JS uncaught exception”
|
||||
### 博客引用: "否则，您置您应用的状态于风险之中"
|
||||
摘自博客 debugable.com, 对于关键字“Node.JS uncaught exception”排名第3
|
||||
|
||||
> …So, unless you really know what you are doing, you should perform a graceful restart of your service after receiving an “uncaughtException” exception event. Otherwise you risk the state of your application, or that of 3rd party libraries to become inconsistent, leading to all kinds of crazy bugs…
|
||||
> …所以, 除非你真的知道你在做什么, 否则你应该在收到一个 "uncaughtException" 异常事件之后, 对你的服务进行一次优雅的重新启动。否则, 您应用的状态, 或和第三方库的状态变得不一致, 都被置于风险之中，导致各种荒唐的错误…
|
||||
|
||||
### Blog Quote: "Blog Quote: There are three schools of thoughts on error handling"
|
||||
From the blog: JS Recipes
|
||||
### 博客引用: "对于错误处理，有三种学院派想法"
|
||||
摘自博客: JS Recipes
|
||||
|
||||
> …There are primarily three schools of thoughts on error handling:
|
||||
1. Let the application crash and restart it.
|
||||
2. Handle all possible errors and never crash.
|
||||
3. Balanced approach between the two
|
||||
> …对于错误处理，主要有三种学院派想法:
|
||||
1. 让应用崩溃并重启.
|
||||
2. 处理所有可能的错误，从不崩溃.
|
||||
3. 两者之间的折中方案
|
||||
|
||||
Reference in New Issue
Block a user