回答:
例外がスローされます -キャッチすることを目的としています。エラーは通常回復不能です。たとえば、データベースに行を挿入するコードブロックがあるとします。この呼び出しが失敗する可能性があります（IDの重複）-この場合は「例外」である「エラー」が必要になるでしょう。これらの行を挿入するときは、次のようなことができます
try {
$row->insert();
$inserted = true;
} catch (Exception $e) {
echo "There was an error inserting the row - ".$e->getMessage();
$inserted = false;
}
echo "Some more stuff";プログラムの実行は続行されます-例外を「キャッチ」したためです。キャッチされない限り、例外はエラーとして扱われます。失敗した後もプログラムの実行を継続できます。
Throwableインターフェイスを使用して）キャッチ可能な例外に変換することで、この混乱を解決する方法が用意されました。問題と助言メッセージ
ErrorVSの子孫との子孫の違いの方が多かったと思いますException。
私は通常set_error_handler、エラーを受け取り、例外をスローする関数に行きます。これにより、何が起こっても、処理する例外があります。@file_get_contents素敵できちんとしたtry / catchは不要です。
デバッグ状況では、ページのようなasp.netを出力する例外ハンドラーもあります。私はこれを道路に投稿していますが、要求された場合は後でサンプルソースを投稿します。
編集：
さらに、約束どおり、サンプルを作成するためにコードの一部を切り取って貼り付けました。私は私のワークステーション上のファイルに以下の保存した、次のことができNO LONGERここで結果を見ない（リンクが壊れているため）。
<?php
define( 'DEBUG', true );
class ErrorOrWarningException extends Exception
{
protected $_Context = null;
public function getContext()
{
return $this->_Context;
}
public function setContext( $value )
{
$this->_Context = $value;
}
public function __construct( $code, $message, $file, $line, $context )
{
parent::__construct( $message, $code );
$this->file = $file;
$this->line = $line;
$this->setContext( $context );
}
}
/**
* Inspire to write perfect code. everything is an exception, even minor warnings.
**/
function error_to_exception( $code, $message, $file, $line, $context )
{
throw new ErrorOrWarningException( $code, $message, $file, $line, $context );
}
set_error_handler( 'error_to_exception' );
function global_exception_handler( $ex )
{
ob_start();
dump_exception( $ex );
$dump = ob_get_clean();
// send email of dump to administrator?...
// if we are in debug mode we are allowed to dump exceptions to the browser.
if ( defined( 'DEBUG' ) && DEBUG == true )
{
echo $dump;
}
else // if we are in production we give our visitor a nice message without all the details.
{
echo file_get_contents( 'static/errors/fatalexception.html' );
}
exit;
}
function dump_exception( Exception $ex )
{
$file = $ex->getFile();
$line = $ex->getLine();
if ( file_exists( $file ) )
{
$lines = file( $file );
}
?><html>
<head>
<title><?= $ex->getMessage(); ?></title>
<style type="text/css">
body {
width : 800px;
margin : auto;
}
ul.code {
border : inset 1px;
}
ul.code li {
white-space: pre ;
list-style-type : none;
font-family : monospace;
}
ul.code li.line {
color : red;
}
table.trace {
width : 100%;
border-collapse : collapse;
border : solid 1px black;
}
table.thead tr {
background : rgb(240,240,240);
}
table.trace tr.odd {
background : white;
}
table.trace tr.even {
background : rgb(250,250,250);
}
table.trace td {
padding : 2px 4px 2px 4px;
}
</style>
</head>
<body>
<h1>Uncaught <?= get_class( $ex ); ?></h1>
<h2><?= $ex->getMessage(); ?></h2>
<p>
An uncaught <?= get_class( $ex ); ?> was thrown on line <?= $line; ?> of file <?= basename( $file ); ?> that prevented further execution of this request.
</p>
<h2>Where it happened:</h2>
<? if ( isset($lines) ) : ?>
<code><?= $file; ?></code>
<ul class="code">
<? for( $i = $line - 3; $i < $line + 3; $i ++ ) : ?>
<? if ( $i > 0 && $i < count( $lines ) ) : ?>
<? if ( $i == $line-1 ) : ?>
<li class="line"><?= str_replace( "\n", "", $lines[$i] ); ?></li>
<? else : ?>
<li><?= str_replace( "\n", "", $lines[$i] ); ?></li>
<? endif; ?>
<? endif; ?>
<? endfor; ?>
</ul>
<? endif; ?>
<? if ( is_array( $ex->getTrace() ) ) : ?>
<h2>Stack trace:</h2>
<table class="trace">
<thead>
<tr>
<td>File</td>
<td>Line</td>
<td>Class</td>
<td>Function</td>
<td>Arguments</td>
</tr>
</thead>
<tbody>
<? foreach ( $ex->getTrace() as $i => $trace ) : ?>
<tr class="<?= $i % 2 == 0 ? 'even' : 'odd'; ?>">
<td><?= isset($trace[ 'file' ]) ? basename($trace[ 'file' ]) : ''; ?></td>
<td><?= isset($trace[ 'line' ]) ? $trace[ 'line' ] : ''; ?></td>
<td><?= isset($trace[ 'class' ]) ? $trace[ 'class' ] : ''; ?></td>
<td><?= isset($trace[ 'function' ]) ? $trace[ 'function' ] : ''; ?></td>
<td>
<? if( isset($trace[ 'args' ]) ) : ?>
<? foreach ( $trace[ 'args' ] as $i => $arg ) : ?>
<span title="<?= var_export( $arg, true ); ?>"><?= gettype( $arg ); ?></span>
<?= $i < count( $trace['args'] ) -1 ? ',' : ''; ?>
<? endforeach; ?>
<? else : ?>
NULL
<? endif; ?>
</td>
</tr>
<? endforeach;?>
</tbody>
</table>
<? else : ?>
<pre><?= $ex->getTraceAsString(); ?></pre>
<? endif; ?>
</body>
</html><? // back in php
}
set_exception_handler( 'global_exception_handler' );
class X
{
function __construct()
{
trigger_error( 'Whoops!', E_USER_NOTICE );
}
}
$x = new X();
throw new Exception( 'Execution will never get here' );
?>答えは部屋の中の象について話すに値する
エラーは、実行時にエラー条件を処理する古い方法です。通常、コードは、コードをset_error_handler実行する前に何かを呼び出します。アセンブリ言語の割り込みの伝統に従います。BASICコードは次のようになります。
on error :divide_error
print 1/0
print "this won't print"
:divide_error
if errcode = X
print "divide by zero error"それがset_error_handler正しい値で呼び出されることを確認するのは困難でした。さらに悪いことに、エラーハンドラを変更する別のプロシージャを呼び出すこともできます。さらに、多くの場合、呼び出しにはset_error_handler呼び出しとハンドラーが散在していました。コードがすぐに制御不能になるのは簡単でした。優れたコードが実際に行っていることの構文とセマンティクスを形式化することで、例外処理が助けとなりました。
try {
print 1/0;
print "this won't print";
} catch (DivideByZeroException $e) {
print "divide by zero error";
}別の関数や、間違ったエラーハンドラーを呼び出すリスクはありません。コードは同じ場所にあることが保証されています。さらに、エラーメッセージが改善されます。
他の多くの言語が望ましい例外処理モデルにすでに進化していたとき、PHPはエラー処理しか持っていませんでした。最終的には、PHPのメーカーが例外処理を実装しました。しかし、古いコードをサポートする可能性が高いため、エラー処理を維持し、エラー処理を例外処理のようにする方法を提供しました。それを除いて、一部のコードがエラーハンドラーをリセットしないという保証はありません。これは、例外処理が提供することを意図していたものでした。
最終回答
例外処理が実装される前にコーディングされたエラーは、おそらくまだエラーです。新しいエラーはおそらく例外です。しかし、エラーや例外となるデザインやロジックはありません。それは、それがコーディングされたときに利用可能であったもの、およびそれをコーディングするプログラマーの好みに基づいています。
ここで追加することの1つは、例外とエラーの処理についてです。アプリケーション開発者にとって、エラーと例外はどちらも「悪いこと」であり、アプリケーションが抱える問題について学習するために記録する必要があります。これにより、長期的に顧客のエクスペリエンスが向上します。
したがって、例外に対して行うのと同じことを行うエラーハンドラを記述することは理にかなっています。
他の回答で述べたように、エラーハンドラーを例外スローアーに設定することは、PHPでエラーを処理する最良の方法です。私は少し簡単な設定を使用します：
set_error_handler(function ($errno, $errstr, $errfile, $errline ) {
if (error_reporting()) {
throw new \ErrorException($errstr, 0, $errno, $errfile, $errline);
}
});オペレーターの作業error_reporting()を続けるためのチェックに注意してください@。また、カスタム例外を定義する必要はありません。PHPにはそのための素晴らしいクラスが1つあります。
例外をスローすることの大きな利点は、例外にスタックトレースが関連付けられているため、問題の場所を簡単に見つけることができることです。
再：「エラーと例外の違いは何ですか？」
ここに違いについて多くの良い答えがあります。私はまだ話されていない何かを追加します-パフォーマンス。具体的には、これは、例外のスロー/処理と戻りコード（成功または何らかのエラー）の処理の違いです。通常、PHPで、この手段は返却falseまたはnull、彼らはそれ以上のそのようなファイルアップロードのように詳述することができます。http://php.net/manual/en/features.file-upload.errors.phpあなたも例外オブジェクトを返すことができます！
さまざまな言語/システムでいくつかのパフォーマンスを実行しました。一般的に言えば、例外処理はエラー戻りコードのチェックよりも約10,000倍遅くなります。
したがって、絶対に、それが開始する前に確実に実行を終了する必要がある場合、まあ、タイムトラベルが存在しないため、運が悪かったことになります。タイムトラベルがない場合、リターンコードは利用可能な最速のオプションです。
編集：
PHPは、例外処理用に高度に最適化されています。実際のテストでは、例外のスローは値を返すよりも2〜10倍遅いだけです。
あなたが探しているanwserはそれだと思います。
エラーは、存在しない$ variableをエコーするなど、慣れている標準的なものです。
例外はPHP 5以降のみで、オブジェクトを処理するときに発生します。
シンプルに保つには：
例外は、オブジェクトを処理するときに発生するエラーです。ただし、try / catchステートメントを使用すると、それらに対して何かを行うことができ、if / elseステートメントと同じように使用されます。これを試してみてください。問題がある場合は問題ありません。
例外を「キャッチ」しないと、標準エラーになります。
エラーは、通常スクリプトを停止させるphpの根本的なエラーです。
Try / catchは、PDOのようなデータベース接続を確立するためによく使用されます。これは、スクリプトをリダイレクトしたい場合や、接続が機能しない場合に何かを行う場合に適しています。ただし、エラーメッセージを表示してスクリプトを停止するだけの場合は、それを必要としないと、キャッチされなかった例外が致命的なエラーになります。または、サイト全体のエラー処理設定を使用することもできます。
それが役に立てば幸い
例外は、throw、errors ...を使用するコードによって意図的にスローされます。
エラーは、通常は処理されないものの結果として発生します。（IOエラー、TCP / IPエラー、null参照エラー）
私はあなたにエラー制御の最も変わった議論をするつもりです。
非常に優れたエラーハンドラーを数年前に言語に組み込みましたが、一部の名前は変更されましたが、エラー処理の原則は現在も同じです。私はカスタムビルドのマルチタスクOSを使用しており、メモリリーク、スタックの増加、クラッシュを発生させることなく、すべてのレベルのデータエラーから回復できなければなりませんでした。したがって、エラーと例外がどのように動作する必要があるか、およびそれらがどのように異なるかについての私の理解は次のとおりです。トライキャッチの内部がどのように機能するのか私にはわからないので、ある程度は推測しています。
エラー処理のために最初に発生するのは、プログラムのある状態から別の状態にジャンプすることです。それはどのように行われますか？私はそれに行きます。
歴史的に、エラーはより古くて単純であり、例外はより新しく、もう少し複雑で機能的です。エラーは、それらをバブルアップする必要があるまで正常に機能します。これは、上司に困難な問題を渡すことと同じです。
エラーは、エラー番号のような数値である場合があり、1つ以上の関連する文字列を伴う場合もあります。たとえば、ファイル読み取りエラーが発生した場合、それが何であるかを報告でき、おそらく正常に失敗する可能性があります。（ああ、それは昔のようにクラッシュするだけのステップアップです。）
例外についてよく言われないのは、例外が特別な例外スタックに階層化されたオブジェクトであることです。これはプログラムフローのリターンスタックのようなものですが、エラーの試行とキャッチのためだけに戻り状態を保持します。（私は以前それらをePushとePopと呼んでいましたが、？AbortはePopとそのレベルに回復する条件付きスローでしたが、Abortは完全なダイまたは出口でした。）
スタックの一番下には、最初の呼び出し元に関する情報があります。これは、外側の試行が開始されたときの状態を知っているオブジェクトです。これは、多くの場合、プログラムが開始されたときです。その上、またはスタックの次のレイヤーは、upが子で、downが親で、次の内側のtry / catchブロックの例外オブジェクトです。
トライの内側にトライを入れると、内側のトライを外側のトライの上に重ねます。内部トライでエラーが発生し、内部キャッチがそれを処理できないか、エラーが外部トライにスローされると、制御が外部キャッチブロック（オブジェクト）に渡され、エラーを処理できるかどうかが確認されます。あなたの上司。
したがって、このエラースタックが実際に行うことは、プログラムフローとシステム状態をマークおよび復元できることです。つまり、問題が発生したときに、プログラムがリターンスタックをクラッシュさせたり、他のもの（データ）を壊したりすることがないようにします。したがって、メモリ割り当てプールなどの他のリソースの状態も保存されるため、キャッチが行われたときにそれらをクリーンアップできます。一般に、これは非常に複雑なことになる可能性があるため、例外処理が遅くなることがよくあります。一般に、これらの例外ブロックに入るにはかなりの状態が必要です。
したがって、try / catchブロックの種類は、他のすべてがめちゃくちゃになった場合に戻ることができるように状態を設定します。それは親のようなものです。私たちの生活がめちゃくちゃになったとき、私たちは親の膝の上にフォールバックすることができ、彼らは再び大丈夫にします。
私があなたを失望させなかったことを願っています。
set_error_handler（）が定義されると、エラーハンドラーは例外のハンドラーに似ています。以下のコードを参照してください。
<?php
function handleErrors( $e_code ) {
echo "error code: " . $e_code . "<br>";
}
set_error_handler( "handleErrors" );
trigger_error( "trigger a fatal error", E_USER_ERROR);
echo "after error."; //it would run if set_error_handler is defined, otherwise, it wouldn't show
?>
Errors are generally unrecoverable<-実際、これは本当ではありません。E_ERRORとE_PARSEは、最も一般的な2つの回復不可能なエラーです（他にもいくつかあります）が、devに表示されるエラーの大部分は回復可能です（E_NOTICEなどE_WARNING）。残念ながら、PHPのエラー処理は完全に混乱しています。あらゆる種類のものが不必要にエラーをトリガーします（ファイルシステム関数の大部分など）。一般的な例外は「OOP方式」ですが、残念ながら、PHPのネイティブOOP APIの一部は例外ではなくエラーを使用します:-(