Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes #1197 adds ExtendedErrorHandler info in JP #1227

Merged
merged 2 commits into from
Dec 3, 2021
Merged

Fixes #1197 adds ExtendedErrorHandler info in JP #1227

merged 2 commits into from
Dec 3, 2021

Conversation

wongjas
Copy link
Member

@wongjas wongjas commented Dec 1, 2021

Summary

Updated the extended error handling section of the docs in JP

Requirements (place an x in each [ ])

@wongjas wongjas requested a review from seratch December 1, 2021 23:54
@wongjas wongjas self-assigned this Dec 1, 2021
@codecov
Copy link

codecov bot commented Dec 1, 2021

Codecov Report

Merging #1227 (b2824ed) into main (ab92b69) will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##             main    #1227   +/-   ##
=======================================
  Coverage   73.22%   73.22%           
=======================================
  Files          17       17           
  Lines        1438     1438           
  Branches      431      431           
=======================================
  Hits         1053     1053           
  Misses        300      300           
  Partials       85       85           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ab92b69...b2824ed. Read the comment docs.

@seratch seratch added this to the 3.9.0 milestone Dec 2, 2021
@seratch seratch added the docs M-T: Documentation work only label Dec 2, 2021
Copy link
Member

@seratch seratch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the work! A few revisions are needed

<details class="secondary-wrapper">
<summary class="section-head" markdown="0">
<h4 class="section-head">エラーハンドラーでのさらなるデータを参照する</h4>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The section title needs to be a noun form for consistency

Suggested change
<h4 class="section-head">エラーハンドラーでのさらなるデータを参照する</h4>
<h4 class="section-head">エラーハンドラーでのさらなるデータの参照</h4>


<div class="secondary-content" markdown="0">
グローバルエラーハンドラーでリクエストからのデータをログする必要があるでしょう。または、単に Bolt で指定した `logger` を利用したい場合があるでしょう。
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"There may be" can be "〜したい場合もあるでしょう" or "〜したい場合があるかもしれません". If you say "する必要があるでしょう", this means "you need to do" or "there is a need to do"

Also, "利用したい場合があるでしょう" is not natural.

Suggested change
グローバルエラーハンドラーでリクエストからのデータをログする必要があるでしょう。または、単に Bolt で指定した `logger` を利用したい場合があるでしょう
グローバルエラーハンドラーの中で、リクエストからのデータをログ出力したい場合もあるでしょう。あるいは単に Bolt に設定した `logger` を利用したい場合もあるでしょう

グローバルエラーハンドラーでリクエストからのデータをログする必要があるでしょう。または、単に Bolt で指定した `logger` を利用したい場合があるでしょう。

バージョン 3.8.0 から初め、 `extendedErrorHandler: true` をコンストラクターに渡すとリクエストの `error` 、 `logger` 、 `context` 、 `body`を含むオブジェクトがエラーハンドラーに追加されます。
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
バージョン 3.8.0 から初め、 `extendedErrorHandler: true` をコンストラクターに渡すとリクエストの `error``logger``context``body`を含むオブジェクトがエラーハンドラーに追加されます
バージョン 3.8.0 からは、コンストラクターに `extendedErrorHandler: true` を渡すと、エラーハンドラーはリクエストの `error``logger``context``body` を含むオブジェクトを受け取ります


app.error(({ error, logger, context, body }) => {
// Bolt で指定した logger を使ってエラーをログ出力させる
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// Bolt で指定した logger を使ってエラーをログ出力させる
// Bolt で指定した logger を使ってエラー内容をログ出力


if (context.teamId) {
// デバッグ目的で、`teamId` を使う
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// デバッグ目的で、`teamId` を使う
// デバッグのために teamId を使ってなんらかの処理

バージョン 3.8.0 から初め、 `extendedErrorHandler: true` をコンストラクターに渡すとリクエストの `error` 、 `logger` 、 `context` 、 `body`を含むオブジェクトがエラーハンドラーに追加されます。

リクエストライフサイクル中に、どの時点でもエラーは生じることがあります(例: `context` での特定したプロパティを指定する前に)。また、 `body` オブジェクトに利用できるデータはイベントによって異なります。これらの理由のため、値を利用する前に `context` と `body` オブジェクトに指定するプロパティの有無を確認することをおすすめします。
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few comments:

  • リクエストライフサイクル中に <- this does not make sense. you can say リクエストのライフサイクルの中で
  • どの時点でも <- this is okay but I think more accurate meaning here should be どのタイミングでも
  • 生じる <- We tend to only use 発生する for errors
  • body オブジェクトに利用できるデータ <- this is not correct; "body オブジェクト内で利用可能な/存在するデータ" should be correct.
  • これらの理由のため <- If you use this phrase, これらの理由から would be better
  • オブジェクトに指定するプロパティの有無 <- if you say オブジェクトに存在するかを確認する, that's fine but the current sentence is not smooth and a bit confusing

If I were you, I would translate the sentence this way:

contextbody オブジェクト内にアクセスしたいプロパティが存在するかどうかをチェックすることをおすすめします。なぜなら body オブジェクト内に存在するデータはイベント毎に異なりますし、エラーはリクエストのライフサイクルの中のどんなタイミング(例えば context のプロパティが設定される前)でも発生しうるからです。

@@ -114,6 +114,7 @@ App オプションは、`App` のコンストラクターに渡します。
| `authorize` | 複数のチームでのインストールをサポートする場合に使用する関数。どのトークンが受信イベントに関連づけられているかを判断するのに使用します。`authorize` 関数に渡される元データには、場合によって `userId`、`conversationId`、`enterpriseId`、`teamId`、`isEnterpriseInstall` が含まれます(受信イベントによって異なります)。`authorize` 関数は、`botToken`、`botId`、`botUserId`、または `userToken`を返します。[ビルトインの OAuth サポート](/bolt-js/concepts#authenticating-oauth)を使用する場合、`authorize` 関数は自動的に作成されるため、自分で渡す必要はありません。`authorize` 関数について詳しくは、こちらを参照してください。 |
| `logger` | ビルトインのロガーの代わりにカスタムのロガーを渡すためのオプション。ロガーには特定のメソッドが実装されている必要があります。これには [`Logger` インターフェイス](https://github.com/slackapi/node-slack-sdk/blob/main/packages/logger/src/index.ts)で定義されている `setLevel(level:LogLevel)`、`getLevel()`、`setName(name: string)`、`debug(...msgs: any\[])`、`info(...msgs: any\[])`、`warn(...msgs: any\[])`、`error(...msgs: any\[])` があります。ログ出力の詳細については、[ドキュメント](/bolt-js/concepts#logging)を参照してください。 |
| `logLevel` | 出力するログのレベルを指定するオプション。`LogLevel` の出力に含まれる情報のレベルには、重要度の低い順から高い順に `DEBUG`、`INFO`、`WARN`、`ERROR` があります。デフォルトの `logLevel` は `INFO` に設定されています。ログ出力の詳細については、[ドキュメント](/bolt-js/concepts#logging)を参照してください。 |
| `extendedErrorHandler` | 真偽値を指定するオプションで、 `true` に設定するとさらなるリクエストのコンテキスト情報を含んだオブジェクトがグローバルエラーハンドラーに渡されます。 バージョン 3.8.0 から利用することができます。 デフォルトは `false` です。 より高度なエラーの処理に関する詳細は [API ドキュメント](/bolt-js/ja-jp/concepts#error-handling))を参照してください。 |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
| `extendedErrorHandler` | 真偽値を指定するオプションで、 `true` に設定するとさらなるリクエストのコンテキスト情報を含んだオブジェクトがグローバルエラーハンドラーに渡されます。 バージョン 3.8.0 から利用することができます。 デフォルトは `false` です。 より高度なエラーの処理に関する詳細は [API ドキュメント](/bolt-js/ja-jp/concepts#error-handling))を参照してください。 |
| `extendedErrorHandler` | 真偽値を指定するオプションで、 `true` に設定するとさらなるリクエストのコンテキスト情報を含んだオブジェクトがグローバルエラーハンドラーに渡されます。 バージョン 3.8.0 から利用することができます。 デフォルトは `false` です。 より高度なエラーの処理に関する詳細は [API ドキュメント](/bolt-js/ja-jp/concepts#error-handling)を参照してください。 |

@seratch seratch merged commit b3eb15b into slackapi:main Dec 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs M-T: Documentation work only
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants