mirror of
https://github.com/goldbergyoni/nodebestpractices.git
synced 2025-11-02 02:55:40 +08:00
Merge pull request #116 from YukiOta/ja-trans/2.3
2.3 Distinguish operational vs programmer errors の翻訳
This commit is contained in:
YukiOta
@ -136,13 +136,13 @@
|
||||
|
||||
<br/><br/>
|
||||
|
||||
## ![✔] 2.3 Distinguish operational vs programmer errors
|
||||
## ![✔] 2.3 操作上のエラーとプログラマーのエラーを区別する
|
||||
|
||||
**TL;DR:** Operational errors (e.g. API received an invalid input) refer to known cases where the error impact is fully understood and can be handled thoughtfully. On the other hand, programmer error (e.g. trying to read undefined variable) refers to unknown code failures that dictate to gracefully restart the application
|
||||
**TL;DR:** 操作上のエラー（例: API が無効な入力を受け取る）は、エラーの影響が十分に理解され、そして丁寧に処理される既知のエラーのことを指します。一方で、プログラマーのエラー（例: 未定義の変数を参照しようとする）は、アプリケーションをすぐさま再起動させる、未知のコードエラーのことを指します。
|
||||
|
||||
**Otherwise:** You may always restart the application when an error appears, but why let ~5000 online users down because of a minor, predicted, operational error? the opposite is also not ideal – keeping the application up when an unknown issue (programmer error) occurred might lead to an unpredicted behavior. Differentiating the two allows acting tactfully and applying a balanced approach based on the given context
|
||||
**さもないと:** エラーが発生したときに毎回アプリケーションを再起動しているかもしれませんが、さほど重要でない、予測可能な、操作上のエラーを原因としてなぜ ~5000 人規模のオンラインユーザーをダウンさせるのでしょうか？その逆もまた理想的ではありません ー 未知のエラー（プログラマーのエラー）が発生したときにアプリケーションをそのまま起動し続けることは、予想外の振る舞いに繋がるかもしれません。この２つを区別することで、機転の利いた振る舞いをさせ、与えられたコンテキストに基づいた適切なアプローチを適用させることができます。
|
||||
|
||||
🔗 [**Read More: operational vs programmer error**](/sections/errorhandling/operationalvsprogrammererror.md)
|
||||
🔗 [**さらに読む: 操作上のエラーとプログラマーのエラーを区別する**](/sections/errorhandling/operationalvsprogrammererror.japanese.md)
|
||||
|
||||
<br/><br/>
|
||||
|
||||
|
||||
@ -1,20 +1,20 @@
|
||||
# Distinguish operational vs programmer errors
|
||||
# 操作上のエラーとプログラマーのエラーを区別する
|
||||
|
||||
### One Paragraph Explainer
|
||||
### 一段落説明
|
||||
|
||||
Distinguishing the following two error types will minimize your app downtime and helps avoid crazy bugs: Operational errors refer to situations where you understand what happened and the impact of it – for example, a query to some HTTP service failed due to connection problem. On the other hand, programmer errors refer to cases where you have no idea why and sometimes where an error came from – it might be some code that tried to read an undefined value or DB connection pool that leaks memory. Operational errors are relatively easy to handle – usually logging the error is enough. Things become hairy when a programmer error pops up, the application might be in an inconsistent state and there’s nothing better you can do than to restart gracefully
|
||||
操作上のエラーとプログラマーのエラーという 2 つのエラーを区別することは、アプリケーションのダウンタイムを最小化し、とんでもないバグを避ける手助けになります: 操作上のエラーは、発生したことおよびその影響を理解できるエラー状態のことを指します ー 例えば、接続の問題が原因となってある HTTP サービスに対するクエリが失敗した状況などです。一方で、プログラマーのエラーは、エラーがなぜ起こったのか、そしてどこで発生したのかわからないエラー状態のことを指します ー これは、あるコードが未定義の値を参照している場合や、DB コネクションプールがメモリをリークしている場合などがあります。操作上のエラーは比較的処理が簡単です ー 通常、エラーをロギングするだけで十分です。プログラマーのエラーが発生した場合は厄介であり、アプリケーションが不安定な状況に陥り、すぐさま再起動するしかありません。
|
||||
|
||||
### Code Example – marking an error as operational (trusted)
|
||||
### コード例 – 操作上のエラーとしてマークする
|
||||
|
||||
<details>
|
||||
<summary><strong>Javascript</strong></summary>
|
||||
|
||||
```javascript
|
||||
// marking an error object as operational
|
||||
// 操作上のエラーとしてエラーオブジェクトをマークする例
|
||||
const myError = new Error('How can I add new product when no value provided?');
|
||||
myError.isOperational = true;
|
||||
|
||||
// or if you're using some centralized error factory (see other examples at the bullet "Use only the built-in Error object")
|
||||
// もしくは、集中化されたエラーファクトリーを使っている場合の例（他の例は「組み込みのエラーオブジェクトのみを使用する」のセクションをご覧ください）
|
||||
class AppError {
|
||||
constructor (commonType, description, isOperational) {
|
||||
Error.call(this);
|
||||
@ -34,7 +34,7 @@ throw new AppError(errorManagement.commonErrors.InvalidInput, 'Describe here wha
|
||||
<summary><strong>Typescript</strong></summary>
|
||||
|
||||
```typescript
|
||||
// some centralized error factory (see other examples at the bullet "Use only the built-in Error object")
|
||||
// 集中化されたエラーファクトリーを使っている場合の例（他の例は「組み込みのエラーオブジェクトのみを使用する」のセクションをご覧ください）
|
||||
export class AppError extends Error {
|
||||
public readonly commonType: string;
|
||||
public readonly isOperational: boolean;
|
||||
@ -42,7 +42,7 @@ export class AppError extends Error {
|
||||
constructor(commonType: string, description: string, isOperational: boolean) {
|
||||
super(description);
|
||||
|
||||
Object.setPrototypeOf(this, new.target.prototype); // restore prototype chain
|
||||
Object.setPrototypeOf(this, new.target.prototype); // プロトタイプチェーンを復元する
|
||||
|
||||
this.commonType = commonType;
|
||||
this.isOperational = isOperational;
|
||||
@ -51,35 +51,35 @@ export class AppError extends Error {
|
||||
}
|
||||
}
|
||||
|
||||
// marking an error object as operational (true)
|
||||
// 操作上のエラーとしてエラーオブジェクトをマーク (true の部分)
|
||||
throw new AppError(errorManagement.commonErrors.InvalidInput, 'Describe here what happened', true);
|
||||
|
||||
```
|
||||
</details>
|
||||
|
||||
### Blog Quote: "Programmer errors are bugs in the program"
|
||||
### ブログ引用: "Programmer errors are bugs in the program"（プログラマーのエラーはプログラムにおけるバグです）
|
||||
|
||||
From the blog, Joyent ranked 1 for the keywords “Node.js error handling”
|
||||
ブログ Joyent （“Node.js error handling”というキーワードで 1 位）より
|
||||
|
||||
> …The best way to recover from programmer errors is to crash immediately. You should run your programs using a restarter that will automatically restart the program in the event of a crash. With a restarter in place, crashing is the fastest way to restore reliable service in the face of a transient programmer error…
|
||||
> …プログラマーのエラーから復帰する最も良い方法は直ちにクラッシュさせることです。プログラムがクラッシュしたときに自動的に再起動してくれるリスターターを備えた、プログラムを動かすべきです。リスターターを備えている場合、一時的なプログラマーのエラーに直面した際に、安定したサービスへと復旧させるための一番手っ取り早い方法は、クラッシュさせることになります。
|
||||
|
||||
### Blog Quote: "No safe way to leave without creating some undefined brittle state"
|
||||
### ブログ引用: "No safe way to leave without creating some undefined brittle state"（不明瞭で不安定な状態を作り出すことなしに、安全に中断する方法はありません）
|
||||
|
||||
From Node.js official documentation
|
||||
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 の挙動の性質上、参照をリークさせたり、不明瞭で不安定な状態を作り出したりすることなく、安全に「中断したところから再開する」方法はほぼありません。投げられたエラーに対応する最も安全な方法は、プロセスをシャットダウンすることです。もちろん、通常のウェブサーバーでは、多くのコネクションがオープン状態になっているかもしれず、エラーが他の誰かによって引き起こされたからといって、それらを急にシャットダウンすることは合理的ではありません。より良いアプローチは、エラーの引き金となったリクエストにエラーレスポンスを送り、他のリクエストは通常の時間内に終了するようにして、そのワーカーにおいて新しいリクエストの受信を停止することです。
|
||||
|
||||
### Blog Quote: "Otherwise you risk the state of your application"
|
||||
### ブログ引用: "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: "There are three schools of thoughts on error handling"
|
||||
### ブログ引用: "There are three schools of thoughts on error handling"（エラー処理について、3 つの考え方があります）
|
||||
|
||||
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. A balanced approach between the two
|
||||
> …エラー処理について、主に以下の3つの考え方があります:
|
||||
1. アプリケーションをクラッシュさせ、再起動させる
|
||||
2. 起こりうるすべてのエラーを処理し、決してクラッシュさせない
|
||||
3. 上記 2 つをバランスよく取り入れたアプローチ
|
||||
|
||||
Reference in New Issue
Block a user