mirror of
https://github.com/goldbergyoni/nodebestpractices.git
synced 2025-11-02 02:55:40 +08:00
[Chinese-translation] failfast.chinese.md & useonlythebuiltinerror.chinese.md - init.
This commit is contained in:
50
sections/errorhandling/failfast.chinese.md
Normal file
50
sections/errorhandling/failfast.chinese.md
Normal file
@ -0,0 +1,50 @@
|
||||
# 快速察觉失败,使用专用库验证参数
|
||||
|
||||
|
||||
### 一段解释
|
||||
|
||||
我们都知道如何检查参数和快速失败对于避免隐藏的错误很重要(见下面的反模式代码示例)。如果没有,请阅读显式编程和防御性编程。在现实中,由于对其编码是件恼人的事情(比如考虑验证分层的JSON对象,它包含像email和日期这样的字段),我们倾向于避免做这样的事情 – 像Joi这样的库和验证器轻而易举的处理这个乏味的任务。
|
||||
|
||||
### Wikipedia: Defensive Programming
|
||||
|
||||
Defensive programming is an approach to improve software and source code, in terms of: General quality – reducing the number of software bugs and problems. Making the source code comprehensible – the source code should be readable and understandable so it is approved in a code audit. Making the software behave in a predictable manner despite unexpected inputs or user actions.
|
||||
|
||||
|
||||
|
||||
### Code example: validating complex JSON input using ‘Joi’
|
||||
|
||||
```javascript
|
||||
var memberSchema = Joi.object().keys({
|
||||
password: Joi.string().regex(/^[a-zA-Z0-9]{3,30}$/),
|
||||
birthyear: Joi.number().integer().min(1900).max(2013),
|
||||
email: Joi.string().email()
|
||||
});
|
||||
|
||||
function addNewMember(newMember)
|
||||
{
|
||||
//assertions come first
|
||||
Joi.assert(newMember, memberSchema); //throws if validation fails
|
||||
//other logic here
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
### Anti-pattern: no validation yields nasty bugs
|
||||
|
||||
```javascript
|
||||
//if the discount is positive let's then redirect the user to pring his discount coupons
|
||||
function redirectToPrintDiscount(httpResponse, member, discount)
|
||||
{
|
||||
if(discount != 0)
|
||||
httpResponse.redirect(`/discountPrintView/${member.id}`);
|
||||
}
|
||||
|
||||
redirectToPrintDiscount(httpResponse, someMember);
|
||||
//forgot to pass the parameter discount, why the heck was the user redirected to the discount screen?
|
||||
|
||||
```
|
||||
|
||||
### Blog Quote: "You should throw these errors immediately"
|
||||
From the blog: Joyent
|
||||
|
||||
> A degenerate case is where someone calls an asynchronous function but doesn’t pass a callback. You should throw these errors immediately, since the program is broken and the best chance of debugging it involves getting at least a stack trace and ideally a core file at the point of the error. To do this, we recommend validating the types of all arguments at the start of the function.
|
||||
77
sections/errorhandling/useonlythebuiltinerror.chinese.md
Normal file
77
sections/errorhandling/useonlythebuiltinerror.chinese.md
Normal file
@ -0,0 +1,77 @@
|
||||
# 仅使用内建的错误对象
|
||||
|
||||
|
||||
### 一段解释
|
||||
|
||||
js天生的宽容性及其多变的代码流选项(例如 EventEmitter, Callbacks, Promises等等)迫使开发人员怎么去引发错误时有多的不一致 – 有些人使用字符串,有些人使用自定义的类型。使用Node.js的内置错误对象有助于在你的代码和第三方库之间保持一致性,它还保留了重要信息,比如StackTrace。当引发异常时,这通常是一个好的习惯去使用附加的上下文属性(如错误名称和相关的HTTP错误代码)填充异常。要实现这种一致性和实践,请考虑使用附加属性扩展错误对象,见下面的代码示例。
|
||||
博客引用:“I don’t see the value in having lots of different types”
|
||||
摘自博客Ben Nadel, 对于关键字“Node.JS错误对象”,排名第五
|
||||
…就我个人而言,我不认为有很多不同类型的错误对象的价值——JavaScript作为一种语言,似乎不符合基于构造函数的错误捕获。因此,区分对象属性似乎比在构造函数类型上区分要容易得多…
|
||||
|
||||
|
||||
|
||||
### Code Example – doing it right
|
||||
|
||||
```javascript
|
||||
//throwing an Error from typical function, whether sync or async
|
||||
if(!productToAdd)
|
||||
throw new Error("How can I add new product when no value provided?");
|
||||
|
||||
//'throwing' an Error from EventEmitter
|
||||
const myEmitter = new MyEmitter();
|
||||
myEmitter.emit('error', new Error('whoops!'));
|
||||
|
||||
//'throwing' an Error from a Promise
|
||||
return new promise(function (resolve, reject) {
|
||||
Return DAL.getProduct(productToAdd.id).then((existingProduct) =>{
|
||||
if(existingProduct != null)
|
||||
reject(new Error("Why fooling us and trying to add an existing product?"));
|
||||
|
||||
```
|
||||
|
||||
### Code example – Anti Pattern
|
||||
|
||||
```javascript
|
||||
//throwing a String lacks any stack trace information and other important properties
|
||||
if(!productToAdd)
|
||||
throw ("How can I add new product when no value provided?");
|
||||
|
||||
```
|
||||
|
||||
### Code example – doing it even better
|
||||
|
||||
```javascript
|
||||
//centralized error object that derives from Node’s Error
|
||||
function appError(name, httpCode, description, isOperational) {
|
||||
Error.call(this);
|
||||
Error.captureStackTrace(this);
|
||||
this.name = name;
|
||||
//...other properties assigned here
|
||||
};
|
||||
|
||||
appError.prototype.__proto__ = Error.prototype;
|
||||
|
||||
module.exports.appError = appError;
|
||||
|
||||
//client throwing an exception
|
||||
if(user == null)
|
||||
throw new appError(commonErrors.resourceNotFound, commonHTTPErrors.notFound, "further explanation", true)
|
||||
```
|
||||
|
||||
|
||||
### Blog Quote: "A string is not an error"
|
||||
From the blog devthought.com, ranked 6 for the keywords “Node.JS error object”
|
||||
|
||||
> …传递字符串而不是错误导致模块间协作性降低。它打破了和API的约定,可能是执行instanceof Error这样的检查,或想了解更多关于错误的信息。正如我们将看到的,错误对象在现代JavaScript引擎中拥有非常有趣的属性,同时保留传递给构造函数的消息…
|
||||
|
||||
Blog Quote: “All JavaScript and System errors raised by Node.js inherit from Error”
|
||||
|
||||
### Blog Quote: "Inheriting from Error doesn’t add too much value"
|
||||
From the blog machadogj
|
||||
|
||||
> …One problem that I have with the Error class is that is not so simple to extend. Of course you can inherit the class and create your own Error classes like HttpError, DbError, etc. However that takes time, and doesn’t add too much value unless you are doing something with types. Sometimes, you just want to add a message, and keep the inner error, and sometimes you might want to extend the error with parameters, and such…
|
||||
|
||||
### Blog Quote: "All JavaScript and System errors raised by Node.js inherit from Error"
|
||||
From Node.JS official documentation
|
||||
|
||||
> …All JavaScript and System errors raised by Node.js inherit from, or are instances of, the standard JavaScript Error class and are guaranteed to provide at least the properties available on that class. A generic JavaScript Error object that does not denote any specific circumstance of why the error occurred. Error objects capture a “stack trace” detailing the point in the code at which the Error was instantiated, and may provide a text description of the error.All errors generated by Node.js, including all System and JavaScript errors, will either be instances of, or inherit from, the Error class…
|
||||
Reference in New Issue
Block a user