例外を適切に使用する方法

私は言いました: プログラムを開発するとき、コードの 80% はさまざまな例外を処理します。

PHP は柔軟性と単純すぎるため、多くの PHPer は例外処理にあまり興味がありません。そのため、

die("xxx");

exit(" xxx");

このような例外処理ですが、このタイプの例外はプロジェクトの安定性にとって非常に好ましくありません。主な問題は次のとおりです。

1: 通常のフローを乱暴に中断します。仕事。

2: デバッグは非常に困難です。

3: 柔軟性が低すぎます

次に、次の 3 つの問題を見てみましょう:

1: ほとんどの最新のフレームワークには標準の処理プロセスがあります:

_before(); //フロントコントローラーはデータを初期化できます

run(); //ビジネスロジックの処理

_after(); //コントローラーのセットアップ後、および処理後ビジネスを終了する機会があります (リソースのリサイクル、統合ログ記録など)。

ただし、exit や die などの関数がビジネス ロジック処理 (run) で直接使用される場合、現在の PHP スクリプトの実行を直接終了することになり、_after() がスキップされます。これは明らかに規則に沿っていません。通常のロジック。

2: あるページを開いたときに、画面が突然真っ白になってしまい、最終的には何のプロンプトも表示されない孤独な終了を見つけたことがあります。デバッガーにとってコードは悪夢です。

3: 現在は PC インターネットの時代ではなく、モバイル インターネットの割合が大幅に増加しています。このような出力は、直接インターフェイスに遭遇すると終了することがよくあります。クライアントの崩壊を直接引き起こす可能性があります。

正しい使い方は何ですか?

はい、php に付属する例外です。php に付属する例外は非常に強力で使いやすいものですが、おそらく歴史的な理由により、多くの人がこれを使用することに慣れていません。

最初の問題については、フレームワークを設計するときに次のように対処できます。

try {

$ctrl->_before(); >

$ctrl->$method();

$ctrl->_after();

} catch (例外 $e) {

$ ctrl->_atfer(); //例外の後に _after を通常どおり実行させます

throw $e; // 例外を再度スローします

}

例外が発生した後スローされた場合は、Exception クラスに付属する getTrace() メソッドを通じてコールスタックを取得できるため、デバッグが簡単に実行できます。

最後に、set_Exception_handler を使用して例外処理をカスタマイズし、最終的に正しいデータ形式を出力できます。

私がよく使用する例外処理コードの短いセクションを投稿します。

API コード規則を想定します:

{

code: 0, //0 以外は例外を意味します

msg: "", // プロンプト情報、0以外の場合は値あり

data: {} //code=0の場合業務データ,

}

カスタム例外処理クラス

class MyException extends Exception

{

public $realCode = '';

public function __construct($message, $コード = -1)

{

$this->realCode = $code;

parent::__construct($message, $code);

}

public static functionExceptionHandler(Exception $Exception)

{

$model = ZFormater::Exception($Exception); //例外の書式設定

Log::info([var_export($model, true)], '例外'); //ログ書き込み例外

$info = array();

if(property_exists) ($例外, 'realCode')) {

$codeArr =explode('_', $例外->realCode);

if(count($codeArr) > 1) {

$model['code'] = intval($codeArr[0]);

$model['msg'] = $codeArr[1];

)

}

$info['msg'] = $model['message'];

$info['ret'] = empty($model['コード ']) -1 : $model['code'];

if(Request::isAjax()) { 'Json');

}

if('Php' == Request::getViewMode()) { //ページリクエスト、統合例外ページ表示

if ($config['debug_mode']) {

Request:: setTplFile('public/error.php');

} else {

Request::setTplFile( 'public/error.php');

}

}

Response::display($info);

}

RealCode 対応定義:

class ERROR

{

const DEF_MSG = 'システム例外';

//システムレベルの例外コード

const PARAM_ERROR = '1_parameter 例外';

const NEED_LOGIN = '2_ログインが必要';

const USER_ERROR = '3 _ユーザー名が存在しません';

const PASS_ERROR = '4_パスワード例外';

}

set_Exception_handler("MyException::ExceptionHandler"); を通じて例外処理をカスタマイズした後、ビジネス層で例外ロジックが発生したときに、次の例外を一律かつ問題なくスローできます:

throw new MyException(' param xxx error', ERROR::PARAM_ERROR);

その場合、最終的な出力 API は次のようになります:

{

" code": 1,

"msg": "パラメータ例外"

}

このようにして、終了して死ぬことに別れを告げることができます。

追記: 上記のコードのほとんどは zphp フレームワークから取得したものです。詳細については、ZPHP フレームワークを参照してください: https://github.com/shenzhe/zphp

--- ------- ---大きな分かれ目----------------

PHPライスライス（phpfamily）は、信頼できる人々の集団によって設立されました。味わう価値のあるものを PHPer Food に提供したいと考えています。

この記事はもともとトン兄弟によって作成されたものです。転載する場合は、出典情報と次の QR コードを明記してください (長押しすると、続く QR コードがわかります):