はじめに
kintoneを利用していて、「何かエラーが起きているようだが、詳細は不明」 という状況に遭遇することはないでしょうか。
詳細がまったくわからない状態からの調査は、原因の究明に時間がかかりやすくなってしまいます。
例外処理を適切に実装することは、こうしたエラーが発生した際の原因特定に役立ちます。
この記事では、kintoneの例外処理の設計と実装について解説します。
一定の可用性と信頼性が求められるカスタマイズで、考慮したい例外処理の設計とその実装方法を紹介します。
例外処理とは
例外処理(Exception handling)は、プログラミングやシステム設計において、予期しないエラーや異常状態に対処するためのしくみです。
プログラムの実行中にエラーが発生した場合、例外処理はそのエラーを捕捉(キャッチ)し、適切な処理を行います。
「予期しないエラーは発生する」という前提のもとで、コストとのバランスを考慮しながら、さまざまな事象に対処する例外処理の設計と実装が重要です。
JavaScriptにおける例外処理
最初に、例外を考慮しない、小さな関数の動作確認から進めていきましょう。
次のコードは、単純な掛け算の結果を返す関数です。
|
|
8行目で数字の1.1を渡すつもりが、誤って '1,1' という文字列を渡しています。
ブラウザーや標準入力からユーザー情報を受け取る場合によくあるミスかと思います。
このような入力ミスに対応するため、3行目のisNaN()
にて、チェックを行っているので問題ないようにも見えます。
では、ブラウザーの開発者モードで実行し、結果をみてみましょう。
結果をみてみると、何も値を返さない結果として、変数result
にはNaN(非数を表すオブジェクト)が格納されています。
エラーメッセージも出力され、関数呼び出し後のconsole.log()
も実行されているので問題ないようにも見えます。
次に、関数を呼び出し、引数を渡しているところを以下に変更して実行してみましょう。
|
|
実行してみると、Uncaught TypeError: というメッセージが出力されました。
isNaN組込み数の実行時に、例外エラーが発生し、処理を中断しています。
エラーメッセージ、計算結果ともに何も出力されないため、ユーザーは何が起きたかわかりません。
では次に、JavaScriptの実行時エラーが発生する場合に備えて、例外処理を実装してみましょう。
以下のように、try/catch/finally文を用いて例外処理を実装します。
try/catch/finally構文の各ブロックの記述については、 MDNの説明 を参照してください。
|
|
実行した結果、プログラムは意図しない所で停止することなく、処理が制御されました。
tryブロックの中で呼び出した先の、multiply
関数内で発生した例外処理でも、呼び出し元のブロック内で発生した例外と同様に捕捉できます。
4行目のconsole.log()
をthrow()
文に変更しますisNaN()
チェックの結果がtrue
になったときにも例外を発生させることができます。
|
|
以下のように、エラーの発生原因を変更し、再度確認してみましょう。
|
|
例外処理を実装することにより、発生する事象に即した対応と、ユーザーに伝えたい情報を出力できます。
実装者が、発生しうる例外を想定し、制御できているということがポイントになります。
この例では、入力データを計算に利用することを想定し、try/catch/finally文を使うことで、実行時にTypeErrorが発生しても例外を処理できることを確認しました。
コールバック関数における例外処理
コールバック関数とは
ここでは、あらためてコールバック関数について説明します。
すでにJavaScriptのコールバックや非同期のしくみについて理解されている方は、このセクションを読み飛ばしていただいて結構です。
次の例は、関数の第3引数に計算自体を行う関数multiply
を渡し、callTask()
は指定された関数を呼び出すプログラムです。
|
|
これは、関数も1つの変数として取り扱えるJavaScriptの言語特性を利用したものです。
「他の関数に呼び出してもらうための関数」と呼ばれる所以の振る舞いが確認できるかと思います。
非同期処理における例外処理
上記の例では、コールバック関数を使うメリットがわかりにくいかと思います。
コールバック関数は、「処理が終わってから、この関数を実行してほしい(いったん仕事は依頼するが呼び出し元では次の作業に入りたい)」などのユースケースでよく用いられます。
ただし、非同期処理での例外処理は注意が必要となりますので、その振る舞いについて確認します。
|
|
非同期の処理を行っているため、正常終了時の結果として、計算結果の出力前に処理終了のメッセージが出力されていますが、先に述べたように、これは正しい振る舞いとなります。
次に、先ほど実施したように、エラーデータを渡してみます。
|
|
tryブロックでmultiply
をコールバック関数として渡していますが、実際の計算は非同期の遅延処理を行うsetTimeout()
の中で非同期的に実行されています。
JavaScriptでは、非同期的に発生した例外は同期処理の中で捕捉できません。
コールバック関数のmultiply
が実行されるころには、同期処理のtryブロックの処理が終わっているからです。
そのため、非同期処理で発生した例外を捕捉するには、次のどちらかの方法で対処します。
- 非同期の処理内でtry-catchを使用する。
- 非同期を同期的に扱う「Promise/async/await」を使用する。
非同期の処理内でtry-catchを使用する方法
非同期の処理setTimeout()
内でtry-catchを使用する方法です。
こちらの方法の場合、以下のデメリットがあります。
setTimeout()
の終了を補足できないので、callSyncTask()
終了後に追加で処理を行うことができない。setTimeout()
内でプログラムを完結する必要があるので、処理の流れが不鮮明になりやすい。
callSyncTask()
終了後に追加で処理を行うといった場合は、後述の「Promise/async/await」の方法で実現できます。
|
|
非同期の中での同期処理を実現する「Promise/async/await」を使用する方法
Promise/async/awaitを使うと、非同期処理を同期的な処理と同様に書くことができます。
非同期の処理内でtry-catchを使用する方法と比較しても、より自然な処理の流れで実現できます。
また、callSyncTask()
処理後に追加で動作を加えることも可能です。
|
|
Promise/async/awaitにつきましては、 Promiseとasync/await でもわかりやすく解説させていただいていますので、参考にしてください。
kintone開発における例外設計
ここまで、基本的な例外処理の振る舞いと、非同期処理についての考慮点について説明しました。
ここからは、実際のkintoneカスタマイズにおいて発生する例外についてです。
例外処理を考慮しない場合
動作の確認には、
kintoneアプリストア
にある
顧客リスト
を使います。
該当のアプリを開き、次のコードをブラウザーの開発者モードで実行します。
|
|
デバックモードで実行し、正常に処理が行われることを確認します。
次に、idキーの値を存在しないレコードIDに変更し、エラーが起きることを確認します。
例外処理の実装はされていない為、コンソールにエラーは出力されますが、ユーザー画面には何も表示されません。
補足
ここで利用している、kintone REST APIリクエストを送信するJavaScript API、kintone.api()
は、以下の形式で呼び出せます。
|
|
ここまで例外の振る舞いを実際に確認していると、すでにお気付きかもしれませんが、この場合の例外処理は、failureCallback()
関数部に記述できます。
さっそく実装して、確認してみましょう。
|
|
次の画面のように「指定したレコード(id:100)が見つかりません」というメッセージが表示されています。
メッセージが出ることで、ユーザーに何が起きているかを伝えられるようになりました。
次に、コンソールから実行しているユーザーに対して、kintoneのアクセス権を設定して動作を確認してみます。
No | アクセス権 | エラーハンドリング |
---|---|---|
1 | アプリのアクセス権がないケース | errorオブジェクト |
2 | レコードのアクセス権がないケース | errorオブジェクト |
3 | フィールドのアクセス権がないケース | 該当フィールドがrecordオブジェクトに返却されない |
No.1、No.2では、カスタマイズコードからのアクセスは例外処理によって適切なメッセージが表示されます。
No.3では、参照しているkintoneフィールド「会社名」にアクセス権を設定しました。
kintone.api()
において、failureCallback()
を実装したにもかかわらず、再びエラーを捕捉できなくなりました。
この振る舞いは、以下のような動作になっています。
- 「会社名」フィールドに対し、アクセス権を設定し操作ユーザーの閲覧権限が外されている。
- record.jsonのレスポンスには、閲覧権限のあるフィールドのみが返却される。
- クライアントからアクセスしようとした「会社名」フィールドのjsonキーが存在しないため、実行時エラーになる。
- No.1およびNo.2は、kintoneサーバー上で検出できるエラーだったため、
failureCallback()
の処理が実行された。 - No.3では、api自体は正常に動作しているため、
successCallback()
が実行され、そこで捕捉できないエラーとなる。
したがって、この場合、クライアントサイドでも例外処理を実装する必要があります。
次のコードを実行し、結果をみてみましょう。
|
|
実行した結果、エラーメッセージが表示されています。
実行時エラーのメッセージをそのまま出力しているので、わかりにくいですが、例外を捕捉し制御できていることが確認できます。
まとめ
- 一定の信頼性が求められるカスタマイズについて、例外処理を実装しましょう。
- 非同期処理における例外処理は、非同期部分、同期部分それぞれの例外発生を考慮し必要に応じた実装をしましょう。
- kintoneカスタマイズにおいては、例外の事象がサーバーサイドで起きるのか、クライアントサイドで起きるのかを考慮し、それぞれ適切に実装しましょう。
おわりに
kintone.api()
には、今回説明させていただいたコールバックの処理で例外に対応するほか、該当のコールバックを省略することにより、kintone.Promise
オブジェクトが返却され、Promiseの機能を用いた実装も可能です。
Promiseオブジェクトが返却される際に、asnyc/awaitを活用した例外の処理方法はまた異なります。
その点につきましては、また機会がございましたら。