エラーの処理方法で暗中模索

ファイルのコピーで使ったような「die」による強制終了は、ローカルで実行する分には問題はないと思うが、公開しているCGIのエラー処理を「die」で済ますのはあまりよろしくない。

例えば、掲示板などのスクリプトで、名前を入力し忘れて投稿した時とかに「致命的なエラー」で強制終了（表示としては「500 Internal Server Error」になる）されたらどうだろう？
しかも、その時にブラウザの「戻る」で戻ったら全部消えていた、とかだったらどうだろう？
ユーザーから見れば不親切だ。
名前が抜けているのなら、名前を入力しなおせば良いはずだ。
エラーの種類としては、処理を続けることができなくなる「（実際の意味での）致命的なエラー（データファイルがない、ファイルに書き込みできない、など）」もあるだろうからある程度は仕方ないにしても、「致命的ではないエラー（名前が抜けている、メールアドレスが不適切、など）」は、ユーザーの支障にならないようにしておきたいところだ。

…というふうに、いつも思ってはいるのだが、エラーの処理は何かと面倒くさい。
とりあえず、「die」しておいてひと通りの処理を作ることが多いが、実際にdieで強制終了されると、それはそれでエラーの確認に手間がかかる。

ウェブで公開する前提のCGIを開発している時にエラーを把握する方法はいくつかあるが、私はCGI::Carpの機能を使うのが手軽で簡単のわりには便利だし十分実用に耐えると思う。

1
2
3
4
5
6
7
8
9


#!/usr/bin/perl -T
# 日本語(EUC-JP)
BEGIN {
    use CGI::Carp qw(fatalsToBrowser); # 500エラー時でもエラー情報をブラウザへ出力
    open CGILOG, ">> ./cgi.log" or die 'Can not open file. ">> ./cgi.log"';
    CGI::Carp::carpout(*CGILOG);
}
use strict;
use warnings;

何かを作ろうと思ったら、とりあえずこのコードを使って書き始める。

開発の環境がWindowsという事もあり文字コードの問題にも頭を悩ませているが、エディタはPerlEditorを、ウェブサーバはAN HTTPDを使っている。
「AN HTTPD」には「CGIの出力を検査」する機能もあるのでそっちを使うのも手だが、本番運営時には無防備になるので私はあまり使わない。設定がApacheに比べて簡単だから使っている。
「PerlEditor」は、変数エクスプローラが便利で手放せない。Perlを覚えたての頃は「シフトＪＩＳで書く場合の注意点」をそこらじゅうで見た。そういうのが面倒だから、最初から「文字コードはEUC-JPで作ろう」というふうに思ったし、そのためにソフトも（それなりに）探した。
今のところ、文字コードの認識についても（ある程度の日本語が書いてあれば）ほとんど問題ないので必要十分。開発がストップしているのが残念ではあるが、私的には今以上にPerl/CGI用の機能があっても多分使わないような気がする。
…というか、実際「ツール」メニューは使ってない。
使っている機能は、画面に出ている変数エクスプローラ、キーワード、メモと文字コード関係くらいで、あとは普通のエディタとして使っている。

閑話休題。「fatalsToBrowser」をインポートすることで文法エラーなどの実行前のエラーもブラウザで表示できるようにしてくれるので、デバッグがブラウザでできるようになる。
ただし、エラーには色々な情報が含まれてしまうので、セキュリティを考えると公開するときにはコメントにしておく必要があるだろう。
その次の2行は、エラー出力を「cgi.log」に溜め込んでいくようにしている。こちらは「fatalsToBrowser」とは無関係に動作する。動作には多少の負荷はかかるだろうが、レンタルサーバなどを使っていてサーバのエラーログが手に入りにくい場合は重宝するだろう。