Why are SafeIllegalArgumentExceptions 400s?

オープン
#1,311 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
java
領域
api, backend

調査の方向性

まず、SafeIllegalArgumentException と checkArgument が API の例外マッピングでどのように処理されるかを追跡します。400 レスポンスがどこで生成されるかを確認し、クライアントエラーに対する既存の明示的な経路を特定します。無関係な内部障害が 400 レスポンスにならず、意図的なクライアントエラー処理が明示的なままになれば完了です。

索引モデルが issue の本文から書いたものです。

説明

Now that we push for using the logsage preconditions everywhere, this means that random bugs deep in the code will effectively cause 400s. The philosophy elsewhere on our api seems to be intentionality and being very careful about what we expose, etc

Additionally, it's kind of subtle and confusing that checkState is a 500 and checkArgument is a 400, even when they have nothing to do with a direct client input.

What happened?

checkArgument causes 400s even when having nothing to do with client issues

What did you want to happen?

Only getting 400s from client issues. Presumably we should have to be explicit about what's a 400 (this is currently true in most other cases).

Essentially, I propose that there's not an exception mapper for this.

主要言語
Java
スター
96
フォーク
95
平均マージ
8分
マージ済み PR(30日)
55

環境構築

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

palantir/conjure-java-runtime のほかの issue

palantir/conjure-java-runtime の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。