関連記事
【開発実況シリーズ】Web日報登録システムを作る #13 管理者：社員別月別リスト
2021.02.22
2022.01.15
【開発実況シリーズ】Web日報登録システムを作る #14 エラー処理の実装
この記事の動画版はこちら（画像クリックでYoutubeに飛びます）
チャンネル登録お願いします！
今回は、開発実況シリーズ「Web日報登録システム」の第14回ということで、前回の続きを進めていきたいと思います。
前回は・・・
前回までで、ひと通りの機能実装が完了しました。
今回からは、アプリの完成度をさらに高めるために、細かい部分の調整を行っていきます。
要望された機能がただ動くだけでなく、こういった仕上げ処理を行うかどうかがアプリの品質向上や、実際に使う際にトラブルの少ないアプリになるかどうかに繋がります。
プロとして活動していく際は、そういった目に見えない部分もしっかりこだわっていきましょう！
今回のアプリの仕上げ作業では、大まかにこのようなことを行っていきます。
①エラー処理の実装
②セキュリティ対策
③リファクタリング＆最終調整
今回は、①エラー処理の実装を行っていきましょう！
エラー処理とは？
エラー処理とは、ユーザーが想定外の異常な操作を行ったり、システムの障害などが発生した場合に、アプリが適切に処理を行うようにすることです。
例えば、入力必須の項目が未入力だったり、正しくない形式のデータが入力されたり、アクセスしてはいけない画面にアクセスされたりといった感じですね。
こういったことが起こった場合に、プログラムが誤動作を起こすことなく、エラーであることを適切にユーザーに明示しなくてはなりません。
これがエラー処理です。
バリデーションの実装
まずは、ユーザーが画面から入力した値をチェックする「バリデーション」を実装していきましょう。
ログイン画面には「社員番号」と「パスワード」の2つの入力項目があり、どちらもログインするための必須入力項目です。
これらが未入力の場合はエラーを表示しなければなりません。
この2つの未入力チェックについては、機能開発時に実装済みですので、このように未入力でログインボタンを押すと、エラーが適切に表示されます。
なので、足りない部分だけ追加で実装していきましょう。
今回、社員番号については、数値形式となっているため、数値以外が入力されたらエラーにするように「形式チェック」を行います。
正規表現という方法を使って、0-9以外の文字が含まれていた場合にエラー表示するようにしましょう。
エラーメッセージはこんな感じで良いですね。
あとは、あまりに長すぎるデータを入力されるとデータベースで不具合が発生する可能性もあるので、データベース設計時に決めたサイズ以上のデータは拒否するように「サイズチェック」も行います。
これで良いですね。
パスワードについては、セキュリティ対策時に暗号化を行うため、今は未入力チェックだけにしておきます。
それでは、テストしてみましょう。
未入力の場合は「未入力エラー」
数値以外を入力した場合は「形式エラー」
20文字以上のデータが入力された場合は「サイズエラー」
それぞれ、正しく表示されていますね。
あとは、HTML側でも「required」属性を付けておけば、未入力の場合にそもそもサーバーへの送信処理が行われないため、より効率的です。
ただ、HTMLやJavaScriptでのクライアントサイドのバリデーションは、ユーザー側で回避することも出来てしまうため、基本は、今回行ったようなサーバーサイドのバリデーションをしっかり実装し、クライアントサイドは補助的な意味合いで実装するのが良いと思います。
管理者のログイン画面にも同様のバリデーションを実装しておきましょう。
次は、日報登録画面のバリデーションを実装していきます。
この画面には「出勤時間」「退勤時間」「休憩時間」そして「業務内容」の4つの入力項目があります。
この内、退勤時間、休憩時間、業務内容は、どのタイミングで入力されるかが分からないため、出勤時間のみを必須入力項目とします。
形式チェックについては、出勤、退勤、休憩時間の3つは「時間形式（00:00）」で入力されているかどうかをチェックします。
サイズチェックについては、業務内容に膨大なデータが入力されないよう、最大2000文字のチェックを行いましょう。
ログイン画面と異なり、この画面にはまだバリデーションの基本処理フローが実装されていないため、まずはそこから実装していきます。
エラー用配列を定義して、ここに、実際のチェック処理を書きます。
バリデーションエラーが無かった場合のみ、登録系の処理を行うようにします。
バリデーションエラーの場合は、モーダルを表示したままにする必要があるため、表示制御部分を調整します。
HTML側にはエラー表示のための、class指定とエラーメッセージ用のパーツを配置します。
別の日のモーダルを表示した際に、前のエラー状態を引き継がないように、モーダル初期化処理ではエラーのclassをクリアするようにしておきます。
これで、OKです。
ここでは1つ1つの詳しい書き方は説明していませんが、講座の方では、このようなバリデーションチェックの書き方を1つ1つ実践しながら学んでいきますので、自分で1から作れるようになりたいという方は、是非チェックしてみてください。
これで基本の処理フローは準備出来たので、次は実際のバリデーションチェックを書いていきます。
まずは、出勤時間の必須チェック。
次は、時間の形式チェック。これも正規表現で書きます。
ちなみに、こういう細かい記述は常に頭で覚えている訳ではなく、以前作ったプログラムの同じような時間形式チェック部分からコピペしています。
退勤時間と休憩時間にも同じ形式チェックを実装します。
最後に、業務内容に2000文字のサイズチェックを実装します。
これで、一通りOKですね。
テストしてみましょう。
出勤時間が未入力の場合、エラーが表示されます。
時間形式以外を入力した場合は、形式エラー。
退勤時間と休憩時間も同じように形式チェックされますね。
不正な形式のデータが入力された場合は、空欄に戻すようにしておきます。
業務内容に2000文字を入力するのは大変なので、一時的に設定を10文字に変えてテストします。
10文字以上を入力すると、サイズエラーが表示されます。
元に戻しておきます。
あれ？エラーが起こると上部の日付部分が今日の日付に変わってしまいますね・・・
何かバグがあるようです。
日付表示部分はここですが、ここが今日の日付が固定表示されてしまっていますね。
おそらくこれが原因っぽいです。
表示している対象日は、この$target_dateという変数に入っているので、
この変数を元に日付表示を行うように変更しましょう。
これで、おそらく大丈夫です。
確認してみましょう。
2/1のモーダルを表示して、入力エラーを発生させます。
エラーが発生した場合も、日付は2/1のままになっているのでOKですね。
無事に直りました。
出勤時間には、HTML側の「required」属性も付けておきましょう。
これで、日報登録画面のバリデーション実装もOKなので、管理者側のプログラムにも同じように実装していきます。
ちゃんとチェックされていますね。
これで、バリデーションの実装は完了です。
エラー遷移の実装
次は、プログラムの処理の中で想定外の不具合が発生したり、システム障害が起こった場合に
適切にエラー画面が表示されるように「エラー遷移」を実装していきます。
例えば、運用している中で突然データベースサーバーが異常停止してしまった場合どうなるでしょうか？
実際に試してみましょう。
XAMPPで、データベースサーバーであるMySQLを停止して
日報登録画面にアクセスしてみます。
このように「データベースに接続出来ない」という旨のメッセージが画面に表示されてしまいます。
ユーザーがアプリを利用していて、いきなりこの画面が表示されたらちょっとビックリしてしまいますよね。
プログラムのパスや、データベース情報なども記載されているため、セキュリティ的にも宜しくないです。
そこで、こういった予期しないシステム障害が発生した場合にも適切なエラーが表示されるようにエラー処理を実装します。
エラー処理は、try-catchという命令を使って実装します。
tryで囲まれた処理の中で何か例外が発生した場合、このcatchブロックにて補足されます。
なので、ここにエラー処理を書いてあげればOKです。
通常は、ここにエラーの原因を追跡出来るようにログの出力を行ったりするのですが、今回は簡単に最低限のエラー画面表示のみを実装します。
エラーが発生したら、このように「error.php」に遷移させるようにします。
エラー画面用のerror.phpを新規に作成します。
ログイン画面をコピーして作りましょう。
こんな感じで良いですね。
では、テストしてみましょう。
先ほどと同じように、MySQLが停止した状態で、日報登録画面にアクセスすると・・・
エラー画面が表示されるようになりました。
エラー画面には、ユーザーが迷わないように、対処方法やこの後に取るべき具体的なアクションを記載しておきましょう。
お問い合わせフォームなどへのリンクを設置するのも良いですね。
こういったエラー画面などは、クライアントとの打ち合わせ時に漏れてしまうことが多いですが、これも重要な画面なので、しっかり提案して摺り合わせするようにしましょう。
なお、try-catchの中では、自分で明示的に例外を発生させることも出来ます。
例えば、管理者側の日報登録画面では、ユーザーIDが必須パラメーターとなっており、指定されなければ、その後の処理に問題が発生してしまいます。
社員一覧からリンクをクリックしてアクセスする通常の画面遷移であれば、このようなことは起きないのですが、例えば、このようにURLを書き換えてアクセスされた場合に、パラメーターが渡ってこない可能性があります。
こういった操作にも対応出来るよう、ユーザーIDが正常に取得出来なかった場合は例外を発生させ、エラー画面を表示するようにしましょう。
これでOKです。
URLを改ざんしてアクセスすると、正常にエラー画面が表示されました。
他の全画面にもtry-catchを追加しておきましょう。
年月指定のパラメーターについても、改ざんされてしまう可能性があるので、
日付として正しくない値や、プルダウンに無い年月が設定された場合はエラーとしましょう。
年月パラメーターの値を日付以外に改ざんしてアクセスすると、このようにエラーが表示されます。
年月パラメーターについては、社員側にもあるので同じように実装しておきます。
これで、このアプリのエラー処理の実装は完了です。
使っていて気になったんですが、モーダルの自動表示は当月以外のデータを見ている時は邪魔なので表示しない方が使いやすいですね。
そのように変更しておきましょう。
より使いやすくなりましたね。
次回予告
今回は①エラー処理の実装を行いました。
①エラー処理の実装
②セキュリティ対策
③リファクタリング＆最終調整
次回は「②セキュリティ対策」を進めていきたいと思います。
徳田 啓（トクタ ケイ）
Webプログラマー暦20年。自分で使うツールは、基本的に1人でゼロから自作。オールマイティなプログラミングの知識とスキルを学べる「フルスタックエンジニア マスター講座」を開講中。生徒さん1人1人に合わせてしっかりサポートしていきます！
プログラミングの実践的なノウハウを発信中！
ぜひフォローしておいてください。
ぜひフォローしておいてください。
