Kotlinの例外とその機能

当社は2年以上にわたってKotlinを生産に使用しています。 個人的に、私は約1年前にこの言語に出会いました。 議論すべき多くのトピックがありますが、今日は機能的なスタイルを含むエラー処理についてお話します。 Kotlinでこれを行う方法を説明します。



（タガンログ企業のオフィスで開催されたこのトピックに関する会議の写真。Maxilektのワーキンググループ（Java）のリーダーであるAlexey Shafranovが話した）

原則としてどのようにエラーを処理できますか？

私はいくつかの方法を見つけました：

• エラーがあるという事実へのポインタとして何らかの戻り値を使用できます。
• 同じ目的でインジケーターパラメーターを使用できますが 、
• グローバル変数を入力してください
• 例外を処理する
• 契約の追加（DbC） 。

各オプションについて詳しく説明します。

戻り値

エラーが発生した場合、特定の「マジック」値が返されます。 スクリプト言語を使用したことがある場合は、おそらく同様の構成体を見たでしょう。

例1：

function sqrt(x) { if(x < 0) return -1; else return √x; } 

例2：

 function getUser(id) { result = db.getUserById(id) if (result) return result as User else return “Can't find user ” + id } 

指標パラメーター

関数に渡される特定のパラメーターが使用されます。 パラメータによって値を返した後、関数内でエラーが発生したかどうかを確認できます。

例：

 function divide(x,y,out Success) { if (y == 0) Success = false else Success = true return x/y } divide(10, 11, Success) id (!Success) //handle error 

グローバル変数

グローバル変数はほぼ同じように機能します。

例：

 global Success = true function divide(x,y) { if (y == 0) Success = false else return x/y } divide(10, 11, Success) id (!Success) //handle error 

例外

私たちは皆、例外に慣れています。 ほとんどどこでも使用されます。

例：

 function divide(x,y) { if (y == 0) throw Exception() else return x/y } try{ divide(10, 0)} catch (e) {//handle exception} 

契約（DbC）

率直に言って、私はこのアプローチを実際に見たことがありません。 長いグーグル検索で、Kotlin 1.3には実際に契約を使用できるライブラリがあることがわかりました。 つまり 関数に渡される変数の条件、戻り値の条件、呼び出し回数、呼び出し元などを設定できます。 そして、すべての条件が満たされていれば、機能は正しく機能したと考えられます。

例：

 function sqrt (x) pre-condition (x >= 0) post-condition (return >= 0) begin calculate sqrt from x end 

正直なところ、このライブラリにはひどい構文があります。 おそらくそれが私がそのようなことをライブで見たことがない理由です。

Javaの例外

Javaに移り、最初からJavaがどのように機能したかを見てみましょう。



言語を設計するときに、2種類の例外が発生しました。

• チェック済み-チェック済み。
• 未チェック-未チェック。

チェック対象の例外は何ですか？ 理論的には、人々がエラーをチェックしなければならないように必要です。 つまり 特定のチェック済み例外が可能な場合は、後でチェックする必要があります。 理論的には、このアプローチにより、未処理のエラーがなくなり、コードの品質が向上するはずです。 しかし、実際にはそうではありません。 少なくとも一度は誰もが空のキャッチブロックを見たと思います。

なぜこれが悪いのでしょうか？

これは、Kotlinドキュメントから直接の古典的な例です-StringBuilderに実装されたJDKからのインターフェイス：

 Appendable append(CharSequence csq) throws IOException; try { log.append(message) } catch (IOException e) { //Must be safe } 

開発者によると、try-catchでラップされた非常に多くのコードに出会ったはずです。catchは空のブロックです。 多くの場合、チェック例外の処理は次の方法で実装されます。単にRuntimeExceptionをスローし、上記のどこかでキャッチします（またはキャッチしません...）。

 try { // do something } catch (IOException e) { throw new RuntimeException(e); //  - ... 

コトリンでできること

例外に関して、Kotlinコンパイラーは次の点で異なります。

1.チェック済み例外と未チェック例外を区別しません。 すべての例外はチェックされていないだけであり、それらをキャッチして処理するかどうかは自分で決定します。

2. Tryは式として使用できます-tryブロックを実行して、そこから最後の行を返すか、catchブロックから最後の行を返すことができます。

 val value = try {Integer.parseInt(“lol”)} catch(e: NumberFormanException) { 4 } //  

3.また、いくつかのオブジェクトを参照するときに同様の構造を使用できます。

 val s = obj.money ?: throw IllegalArgumentException(“ , ”) 

Javaの互換性

KotlinコードはJavaで使用でき、その逆も可能です。 例外を処理する方法は？

• KotlinのJavaからのチェック済み例外は、チェックも宣言もできません（Kotlinにはチェック済み例外がないため）。
• Kotlinで発生する可能性のあるチェック済み例外（たとえば、元々Javaから発生した例外）は、Javaでチェックする必要はありません。
• チェックする必要がある場合は、メソッドの@Throwsアノテーションを使用して例外を検証可能にすることができます（このメソッドがスローできる例外を示す必要があります）。 上記の注釈は、Java互換性のみを目的としています。 しかし、実際には、多くの人がこのメソッドを使用して、原則として、ある種の例外をスローできることを宣言しています。

try-catchブロックの代替

try-catchブロックには重大な欠点があります。 表示されると、ビジネスロジックの一部がキャッチ内に転送され、これは上記の多くのメソッドのいずれかで発生する可能性があります。 ビジネスロジックがブロックまたはコールチェーン全体に分散している場合、アプリケーションの動作を理解するのはより困難です。 また、可読性ブロック自体はコードを追加しません。

 try { HttpService.SendNotification(endpointUrl); MarkNotificationAsSent(); } catch (e: UnableToConnectToServerException) { MarkNotificationAsNotSent(); } 

代替手段は何ですか？

1つのオプションは、例外処理への機能的なアプローチを提供します。 同様の実装は次のようになります。

 val result: Try<Result> = Try{HttpService.SendNotification(endpointUrl)} when(result) { is Success -> MarkNotificationAsSent() is Failure -> MarkNotificationAsNotSent() } 

Tryモナドを使用することができます。 本質的に、それは何らかの値を格納するコンテナです。 flatMapは、このコンテナを操作する方法です。このコンテナは、現在の値と一緒に関数を受け取り、再びモナドを返すことができます。

この場合、呼び出しはTryモナドにラップされます（Tryを返します）。 必要な場所で1か所で処理できます。 出力に値がある場合、次のアクションを実行します。例外がスローされた場合、チェーンの最後で処理します。

機能的な例外処理

Tryはどこで入手できますか？

まず、TryクラスとBothクラスのコミュニティ実装はかなりあります。 それらを使用することも、自分で実装を作成することもできます。 「戦闘」プロジェクトの1つで、Tryの自作の実装を使用しました。1つのクラスで管理し、素晴らしい仕事をしました。
第二に、Kotlinに多くの機能を追加するArrowライブラリがあります。 当然、TryとBothがあります。

それに加えて、結果クラスはKotlin 1.3に登場しました。これについては後で詳しく説明します。

例としてArrowライブラリーを使用してみてください

Arrowライブラリーは、Tryクラスを提供します。 実際には、成功または失敗の2つの状態になります。

• 出金が成功しても、当社の価値は維持されますが、
• 失敗は、コードブロックの実行中に発生した例外を保存します。

呼び出しは次のとおりです。 当然、通常のtry-catchでラップされますが、これはコード内のどこかで発生します。

 sealed class Try<out A> { data class Success<out A>(val value: A) : Try<A>() data class Failure(val e: Throwable) : Try<Nothing>() companion object { operator fun <A> invoke(body: () -> A): Try<A> { return try { Success(body()) } catch (e: Exception) { Failure(e) } } } 

同じクラスでflatMapメソッドを実装する必要があります。これにより、関数を渡してtryモナドを返すことができます。

 inline fun <B> map(f: (A) -> B): Try<B> = flatMap { Success(f(it)) } inline fun <B> flatMap(f: (A) -> TryOf<B>): Try<B> = when (this) { is Failure -> this is Success -> f(value) } 

これは何のためですか？ 結果が複数ある場合に各結果のエラーを処理しないようにするため。 たとえば、さまざまなサービスからいくつかの値を取得し、それらを組み合わせたいとします。 実際、2つの状況が発生する可能性があります。それらを正常に受信して結合したか、何かが落ちました。 したがって、次のことができます。

 val result1: Try<Int> = Try { 11 } val result2: Try<Int> = Try { 4 } val sum = result1.flatMap { one -> result2.map { two -> one + two } } println(sum) //Success(value=15) 

両方の呼び出しが成功し、値を取得した場合、関数を実行します。 成功しなかった場合、Failureは例外を返します。

何かが落ちた場合、次のようになります。

 val result1: Try<Int> = Try { 11 } val result2: Try<Int> = Try { throw RuntimeException(“Oh no!”) } val sum = result1.flatMap { one -> result2.map { two -> one + two } } println(sum) //Failure(exception=java.lang.RuntimeException: Oh no! 

同じ関数を使用しましたが、出力はRuntimeExceptionからの失敗です。

また、Arrowライブラリを使用すると、実際には構文糖、特にバインディングの構文を使用できます。 シリアルflatMapを使用してすべて同じものを書き換えることができますが、バインディングを使用することで読み取り可能にすることができます。

 val result1: Try<Int> = Try { 11 } val result2: Try<Int> = Try { 4 } val result3: Try<Int> = Try { throw RuntimeException(“Oh no, again!”) } val sum = binding { val (one) = result1 val (two) = result2 val (three) = result3 one + two + three } println(sum) //Failure(exception=java.lang.RuntimeException: Oh no, again! 

結果の1つが落ちた場合、出力にエラーが表示されます。

同様のモナドを非同期呼び出しに使用できます。 たとえば、非同期に実行される2つの関数を次に示します。 ステータスを個別に確認せずに、同じ方法で結果を結合します。

 fun funA(): Try<Int> { return Try { 1 } } fun funB(): Try<Int> { Thread.sleep(3000L) return Try { 2 } } val a = GlobalScope.async { funA() } val b = GlobalScope.async { funB() } val sum = runBlocking { a.await().flatMap { one -> b.await().map {two -> one + two } } } 

そして、ここにもっと「戦闘」の例があります。 サーバーへのリクエストがあり、それを処理し、それからボディを取得し、それをすでにデータを返しているクラスにマップしようとします。

 fun makeRequest(request: Request): Try<List<ResponseData>> = Try { httpClient.newCall(request).execute() } .map { it.body() } .flatMap { Try { ObjectMapper().readValue(it, ParsedResponse::class.java) } } .map { it.data } fun main(args : Array<String>) { val response = makeRequest(RequestBody(args)) when(response) { is Try.Success -> response.data.toString() is Try.Failure -> response.exception.message } } 

Try-catchを使用すると、このブロックの読みやすさが大幅に低下します。 この場合、出力でresponse.dataを取得し、結果に応じて処理できます。

Kotlin 1.3の結果

Kotlin 1.3はResultクラスを導入しました。 実際、Tryに似ていますが、いくつかの制限があります。 元々は、さまざまな非同期操作に使用することを目的としています。

 val result: Result<VeryImportantData> = Result.runCatching { makeRequest() } .mapCatching { parseResponse(it) } .mapCatching { prepareData(it) } result.fold{ { data -> println(“We have $data”) }, exception -> println(“There is no any data, but it's your exception $exception”) } ) 

間違っていない場合、このクラスは現在実験的です。 言語開発者は、シグネチャや動作を変更したり、完全に削除したりできるため、現時点ではメソッドまたは変数からの戻り値として使用することは禁止されています。 ただし、ローカル（プライベート）変数として使用できます。 つまり 実際、例から試してみることができます。

結論

私が自分のためにした結論：

• Kotlinの機能エラー処理はシンプルで便利です。
• 古典的なスタイルのtry-catchを介してそれらを処理することを誰も気にしません（それとそれの両方に生命権があります;それとそれの両方が便利です）
• チェックされた例外がないことは、エラーを処理できないことを意味しません。
• 生産に関するキャッチされない例外は、悲しい結果をもたらします。

記事の著者：Alexey Shafranov、ワーキンググループ（Java）のリーダー、Maxilect

PS Runetのいくつかのサイトで記事を公開しています。 VK 、 FB、または電報チャネルのページを購読して、すべての出版物やその他のMaxilectニュースについて学びます。