エレガントな Java 例外を設計するにはどうすればよいでしょうか?

}

上記はモデルの関係であり、ユーザーと配送先住所の関係は 1 対 n の関係です。上記の @Data は lombok という Setter メソッドと Getter メソッドを自動生成するツールを使用していて非常に便利なので、興味のある方はご自身で勉強してみてください。

ダオの紹介

データ接続層には、 spring-data-jpa フレームワークを使用します。このフレームワークでは、フレームワークによって提供されるインターフェイスを継承し、規則に従ってメソッドに名前を付けるだけで、必要なデータベース操作を完了できます。

ユーザーデータベースの操作は次のとおりです:

@リポジトリ

パブリック インターフェイス IUserDao は JpaRepository を拡張します {

}

配送先住所の操作は次のとおりです:

@リポジトリ

パブリック インターフェイス IAddressDao は JpaRepository を拡張します {

}

読者がお分かりのとおり、DAO は JpaRepository を継承するだけで済み、基本的な CURD やその他の操作を完了するのにすでに役立っています。spring-data プロジェクトについて詳しく知りたい場合は、spring の公式ドキュメントを参照してください。異常についての研究。

サービス例外設計

OK、ようやく焦点に到達しました。配送先住所の追加、配送先住所の削除、配送先住所リストの取得など、サービスのいくつかの操作を完了する必要があります。

まずサービス インターフェイス定義を見てください:

パブリック インターフェイス IAddressService {

/**

* 配送先住所を作成します

* @param uid

* @パラメータアドレス

* @戻る＃＃＃＃＃＃*/

アドレス createAddress(Integer uid,Address address);

/**

* 配送先住所を削除

* @param uid

* @param 援助

*/

void deleteAddress(整数 uid,整数補助);

/**

* ユーザーのすべての配送先アドレスをクエリします

* @param uid

* @戻る＃＃＃＃＃＃*/

リスト<アドレス> listAddresses(Integer uid);

}

実装に焦点を当てましょう:

配送先住所を追加

まず、以前にコンパイルした制約を見てみましょう:

入力パラメータ:

ユーザーID＃＃＃＃＃＃ 配送先住所エンティティ情報

制約:

ユーザー ID を空にすることはできません。このユーザーは存在します。

配送先住所の必須フィールドを空にすることはできません

ユーザーがまだ配送先住所を持っていない場合、配送先住所は作成時にデフォルトの配送先住所として設定されます

まず、次のコード実装を見てみましょう:

@オーバーライド＃＃＃＃＃＃ public Address createAddress(Integer uid, Address address) {

//============ 以下は制約です ==============

//1. ユーザー ID を空にすることはできません。このユーザーは存在します。

Preconditions.checkNotNull(uid);

ユーザー user = userDao.findOne(uid);

if(null == ユーザー){

throw new RuntimeException("現在のユーザーが見つかりません!");

}

//2. 配送先住所の必須フィールドを空にすることはできません

BeanValidators.validateWithException(バリデーター, アドレス);

//3. ユーザーがまだ配送先住所を持っていない場合、配送先住所が作成されると、デフォルトの配送先住所

に設定されます。 if(ObjectUtils.isEmpty(user.getAddresses())){

address.setIsDefault(true);

}

//============ 通常実行されるビジネスロジックは以下の通り ==============

address.setUser(ユーザー);

アドレスの結果 = addressDao.save(アドレス);

結果を返す;

}

このうち、上記の 3 つの制約は完了しており、3 つの制約が満たされている場合は通常のビジネス ロジックを実行できますが、満たされていない場合は例外がスローされます (通常は、実行時例外 - ここでは RuntimeException をスローすることをお勧めします)。

上記で使用した次のテクノロジーを紹介します:

Preconfitions.checkNotNull(T t) は Guava の com.google.common.base.Preconditions を使用して判定されます。サービスでは多くの検証が使用されるため、Preconfitions を静的なインポート メソッドに変更することをお勧めします:

1インポート静的 com.google.common.base.Preconditions.checkNotNull;

もちろん、Guava の github にある手順でも、この方法で使用することを推奨しています。

BeanValidators.validateWithException(バリデーター, アドレス);

これは、hibernate によって実装された jsr 303 仕様を使用して行われます。検証する必要があるバリデーターとエンティティを渡す必要があります。したがって、バリデーターの取得方法は次のようになります:

@構成＃＃＃＃＃＃ パブリック クラス BeanConfigs {

@豆＃＃＃＃＃＃ public javax.validation.Validator getValidator(){

新しい LocalValidatorFactoryBean() を返します;

}

}

Validator オブジェクトを取得すると、それをサービスに挿入して使用できます。 @Autowired

プライベート Validator バリデーター ;

では、BeanValidators クラスはどのように実装されるのでしょうか?実は実装は非常に簡単で、jsr303のアノテーションを判断するだけでOKです。

では、jsr 303 アノテーションはどこに書かれているのでしょうか?もちろん、これはアドレス エンティティ クラスに記述されます:

@実在物＃＃＃＃＃＃ @Setter

@Getter

パブリック クラス アドレス {

@Id

@GeneratedValue

プライベート整数 ID;

@NotNull

private String 州;//province

@NotNull

private String city;//city

@NotNull

private String County;//District

private Boolean isDefault = false;//デフォルトのアドレスかどうか

@ManyToOne(cascade={CascadeType.ALL})

@JoinColumn(name="uid")

プライベートユーザー user;

}

判断に必要な制約を記述し、それが合理的であれば業務を実行し、データベースを運用することができます。

この部分の検証が必要である主な理由の 1 つは、検証によってダーティ データの挿入を回避できることです。読者に正式なオンライン経験があれば、そのようなことは理解できるでしょう。コード エラーは許容され、修正されますが、ダーティ データの問題が発生すると、壊滅的な惨事になる可能性があります。プログラムの問題は修正できますが、汚れたデータの外観は回復できない場合があります。このため、ビジネス ロジック操作を実行する前にサービス内の制約を決定する必要があります。

ここでの判断は、ビジネスの観点から行われるビジネス ロジックの判断であり、また、多くのシナリオではさまざまなビジネス条件の制約が存在する可能性があり、要件に応じて判断するだけで済みます。

制約の概要は次のとおりです。

基本的な判定制約（null値などの基本的な判定）

エンティティ属性の制約 (jsr 303 などの基本的な判断を満たす)

ビジネス条件の制約 (要件によって提案されるさまざまなビジネス制約)

これら 3 つのポイントが満たされている場合は、次のステップに進むことができます

さて、これは基本的な判断方法の紹介です。例外設計の問題に戻りましょう。上記のコードは、適切な場所で例外を合理的に判断する方法を明確に記述しています。では、例外を合理的にスローするにはどうすればよいでしょうか?

RuntimeException をスローするだけでは、正常に例外をスローしたとみなされますか?サービス中にスローされる例外には、大きく分けて 2 つのスロー方法があると思います。 ステータス コード RumtimeException

の例外をスローします 指定されたタイプの RuntimeException をスローします

2 つの例外メソッドと比較すると、最初の例外は、すべての例外が RuntimeException 例外をスローすることを意味しますが、ステータス コードが必要です。呼び出し元は、ステータス コードに基づいてサービスがスローしたものの種類を問い合わせることができます。

2 番目のタイプの例外は、サービスでスローされる例外に対して指定された例外エラーをカスタマイズして、例外をスローすることを指します。

一般に、システムに他に特別な要件がない場合は、開発および設計中に 2 番目の方法を使用することをお勧めします。しかし、例えば基本的な判定例外はguavaが提供するクラスライブラリを利用して完全に操作することができます。 JSR 303 例外は、独自のカプセル化された例外判定クラスを使用して操作することもできます。これらの 2 つの例外は基本的な判定であり、特別な例外を指定する必要がないためです。ただし、3 番目の義務条件制約判定でスローされる例外については、指定された種類の例外をスローする必要があります。

のために ＃＃＃＃＃＃ 1throw new RuntimeException("現在のユーザーが見つかりません!");

この必須の例外を判断するための特定の例外クラスを定義します:

パブリック クラス NotFindUserException extends RuntimeException {

public NotFindUserException() {

super("このユーザーは見つかりません");

}

public NotFindUserException(文字列メッセージ) {

スーパー(メッセージ);

}

}

次に、これを次のように変更します:

1throw new NotFindUserException("現在のユーザーが見つかりません!");

または＃＃＃＃＃＃ 1throw new NotFindUserException();

サービス層に対する上記の変更により、コードは次のように変更されます:

@オーバーライド＃＃＃＃＃＃ public Address createAddress(Integer uid, Address address) {

//============ 以下は制約です ==============

//1. ユーザー ID を空にすることはできません。このユーザーは存在します。

checkNotNull(uid);

ユーザー user = userDao.findOne(uid);

if(null == ユーザー){

throw new NotFindUserException("現在のユーザーが見つかりません!");

}

//2. 配送先住所の必須フィールドを空にすることはできません

BeanValidators.validateWithException(バリデーター, アドレス);

//3. ユーザーがまだ配送先住所を持っていない場合、配送先住所が作成されると、デフォルトの配送先住所

に設定されます。 if(ObjectUtils.isEmpty(user.getAddresses())){

address.setIsDefault(true);

}

//============ 通常実行されるビジネスロジックは以下の通り ==============

address.setUser(ユーザー);

アドレスの結果 = addressDao.save(アドレス);

結果を返す;

}

このようなサービスはより安定しており、理解しやすいと思われます。

配送先住所を削除:

入力パラメータ:

ユーザーID＃＃＃＃＃＃ 配送先住所 ID

制約:

ユーザー ID を空にすることはできません。このユーザーは存在します

配送先住所を空にすることはできません。配送先住所は存在します。

この配送先住所がユーザーの配送先住所かどうかを確認します

この配送先住所がデフォルトの配送先住所であるかどうかを確認します。デフォルトの配送先住所である場合、削除できません

上記の配送先アドレスの追加と同様なので詳細は省略しますが、削除のサービス設計は以下の通りです: @Override

public void deleteAddress(整数 uid, 整数補助) {

//============ 以下は制約です ==============

//1. ユーザー ID を空にすることはできません。このユーザーは存在します。

checkNotNull(uid);

ユーザー user = userDao.findOne(uid);

if(null == ユーザー){

新しい NotFindUserException();

をスローします }

//2. 配送先住所を空にすることはできません。配送先住所は存在します

checkNotNull(援助);

アドレス address = addressDao.findOne(aid);

if(null == アドレス){

新しい NotFindAddressException();

をスローします }

//3. この配送先住所がユーザーの配送先住所かどうかを判断します

if(!address.getUser().equals(user)){

新しい NotMatchUserAddressException();

をスローします }

//4. 配送先住所がデフォルトの配送先アドレスであるかどうかを確認し、デフォルトの配送先アドレスである場合は削除できません

if(address.getIsDefault()){

新しい DefaultAddressNotDeleteException();

をスローします }

//============ 通常実行されるビジネスロジックは以下の通り ==============

addressDao.delete(アドレス);

}

NotFindUserException、NotFindAddressException、NotMatchUserAddressException、DefaultAddressNotDeleteException という 4 つの関連例外クラスが設計されており、さまざまなビジネス要件に応じてさまざまな例外がスローされます。

配送先住所リストを取得します:

入力パラメータ:

ユーザーID＃＃＃＃＃＃ 制約:

ユーザー ID を空にすることはできません。このユーザーは存在します。

コードは次のとおりです:@Override

public List