Belki PHP kılavuzunda bir yerde eksik olabilir, ancak bir hata ile istisna arasındaki fark tam olarak nedir? Görebildiğim tek fark, hataların ve istisnaların farklı şekilde ele alınmasıdır. Fakat bir istisnaya ne sebep olur ve bir hataya ne sebep olur?
Yanıtlar:
İstisnalar atılır - yakalanmaları amaçlanır. Hatalar genellikle düzeltilemez. Örneğin, bir veritabanına bir satır ekleyecek bir kod bloğunuz olduğunu söyleyelim. Bu aramanın başarısız olması mümkündür (yinelenen kimlik) - bu durumda bir "İstisna" olan bir "Hata" isteyeceksiniz. Bu satırları eklerken, bunun gibi bir şey yapabilirsiniz.
try {
$row->insert();
$inserted = true;
} catch (Exception $e) {
echo "There was an error inserting the row - ".$e->getMessage();
$inserted = false;
}
echo "Some more stuff";Program yürütme devam edecek - çünkü istisnayı 'yakaladınız'. Bir istisna, yakalanmadığı sürece hata olarak değerlendirilecektir. Başarısız olduktan sonra da programın yürütülmesine devam etmenize izin verecektir.
Throwablearayüz aracılığıyla) bu karmaşayı çözmenin yolunu açtı, hem gerçek sorunlar ve tavsiye mesajları
ErrorVS'nin torunları arasındaki farkla ilgiliydi Exception.
Genelde set_error_handlerhatayı alan ve bir istisna atan bir işleve gidiyorum , böylece ne olursa olsun uğraşmam gereken istisnalarım olacak. Artık @file_get_contentssadece güzel ve düzenli deneme / yakalama yok.
Hata ayıklama durumlarında, asp.net benzeri bir sayfa çıkaran bir istisna işleyicim de var. Bunu yola koyuyorum ama istenirse örnek kaynağı daha sonra göndereceğim.
Düzenle:
Söz verdiğim gibi ek olarak, bir örnek oluşturmak için kodumun bir kısmını kesip yapıştırdım. Benim iş istasyonundaki dosyaya aşağıda kurtardın, şunları yapabilirsiniz ARTIK burada sonuçları görmek (bağlantı bozuk olduğu için).
<?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' );
?>Cevap, odadaki fil hakkında konuşmayı hak ediyor
Hatalar, çalışma zamanında bir hata koşulunu işlemenin eski yoludur. Tipik olarak kod, bir set_error_handlerkodu çalıştırmadan önce olduğu gibi bir şeye çağrı yapar . Montaj dili geleneğini takip ederek kesintiye uğrar. İşte bazı BASIC kodlarının nasıl görüneceği.
on error :divide_error
print 1/0
print "this won't print"
:divide_error
if errcode = X
print "divide by zero error"Bunun set_error_handlerdoğru değerle çağrılacağından emin olmak zordu . Ve daha da kötüsü, hata işleyiciyi değiştirecek ayrı bir prosedüre çağrı yapılabilir. Artı çoğu zaman aramalar, set_error_handleraramalar ve işleyicilerle serpiştirildi . Kodun hızla kontrolden çıkması kolaydı. İstisna yönetimi, iyi kodun gerçekte ne yaptığına dair sözdizimi ve anlambilimini biçimlendirerek kurtarmaya geldi.
try {
print 1/0;
print "this won't print";
} catch (DivideByZeroException $e) {
print "divide by zero error";
}Ayrı bir işlev veya yanlış hata işleyiciyi arama riski yoktur. Kodun artık aynı yerde olması garanti edilmektedir. Ayrıca daha iyi hata mesajları alıyoruz.
PHP, diğer birçok dil zaten tercih edilen istisna işleme modeline evrimleştiğinde, yalnızca hata işlemeye sahipti. Sonunda PHP'nin üreticileri istisna işlemeyi uyguladılar. Ancak eski kodu destekleme olasılığı yüksek olduğundan, hata işlemeyi sürdürdüler ve hata işlemeyi istisna işleme gibi göstermenin bir yolunu sağladılar. Bunun dışında, tam olarak istisna işlemenin sağlaması amaçlanan bazı kodların hata işleyiciyi sıfırlayamayacağının garantisi yoktur.
Son cevap
İstisna işleme uygulanmadan önce kodlanan hatalar muhtemelen hatadır. Yeni hatalar olası istisnalardır. Ancak hangisinin hata, hangisinin istisnası olduğu hiçbir tasarım veya mantık yoktur. Sadece kodlandığı anda mevcut olana ve onu kodlayan programcının tercihine dayanıyor.
Buraya eklenecek bir şey, istisnaları ve hataları ele almakla ilgilidir. Uygulama geliştiricisinin amacı doğrultusunda, hem hatalar hem de istisnalar, uygulamanızın sahip olduğu sorunları öğrenmek için kaydetmek istediğiniz "kötü şeylerdir" - böylece müşterilerinizin uzun vadede daha iyi bir deneyim yaşamaları sağlanır.
Bu nedenle, istisnalar için yaptığınızla aynı şeyi yapan bir hata işleyici yazmak mantıklıdır.
Diğer yanıtlarda da belirtildiği gibi, hata işleyiciyi istisna atıcı olarak ayarlamak PHP'deki hataları işlemenin en iyi yoludur. Biraz daha basit bir kurulum kullanıyorum:
set_error_handler(function ($errno, $errstr, $errfile, $errline ) {
if (error_reporting()) {
throw new \ErrorException($errstr, 0, $errno, $errfile, $errline);
}
});Operatörün çalışmaya error_reporting()devam etmesi için lütfen çeki not edin @. Ayrıca, özel bir istisna tanımlamaya gerek yoktur, PHP'nin bunun için güzel bir sınıfı vardır.
İstisnaları atmanın en büyük yararı, istisnanın kendileriyle ilişkili yığın izine sahip olmasıdır, bu nedenle sorunun nerede olduğunu bulmak kolaydır.
Ynt: "ama bir hata ile istisna arasındaki fark tam olarak nedir?"
Buradaki farklılıklar hakkında pek çok iyi cevap var. Henüz konuşulmamış bir şeyi ekleyeceğim - performans. Spesifik olarak, bu, istisnaları atma / işleme ve bir dönüş kodunu işleme (başarı veya bazı hata) arasındaki fark içindir. Genellikle, php'de bu, geri dönmek anlamına gelir falseveya null, ancak dosya yükleme gibi daha ayrıntılı olabilirler: http://php.net/manual/en/features.file-upload.errors.php olabilirler Bir Exception nesnesi bile döndürebilirsiniz !
Farklı dillerde / sistemlerde birkaç performans çalışması yaptım. Genel olarak, istisna işleme, bir hata dönüş kodunu kontrol etmekten yaklaşık 10.000 kat daha yavaştır.
Yani, daha başlamadan önce yürütmeyi kesinlikle, olumlu bir şekilde bitirmesi gerekiyorsa - şansınız yok çünkü zaman yolculuğu mevcut değil. Zaman yolculuğu olmadan, dönüş kodları mevcut en hızlı seçenektir.
Düzenle:
PHP, istisna işleme için son derece optimize edilmiştir. Gerçek dünya testleri, bir istisna atmanın bir değer döndürmekten yalnızca 2-10 kat daha yavaş olduğunu göstermektedir.
Sanırım aradığınız cevap şu;
Hatalar, var olmayan bir $ değişkenini yankılamak gibi alışkın olduğunuz standart şeylerdir.
İstisnalar yalnızca PHP 5 ve sonrasıdır ve nesnelerle uğraşırken ortaya çıkar.
Basit tutmak için:
İstisnalar, nesnelerle uğraşırken aldığınız hatalardır. Try / catch deyimi onlar hakkında bir şeyler yapmanıza izin verir ve if / else deyimine çok benzer şekilde kullanılır. Bunu yapmaya çalışın, sorun önemli değilse bunu yapın.
Bir istisnayı "yakalayamazsanız", bu standart bir hataya dönüşür.
Hatalar, genellikle betiğinizi durduran temel php hatalarıdır.
Try / catch, genellikle PDO gibi veritabanı bağlantıları kurmak için kullanılır; bu, betiği yeniden yönlendirmek veya bağlantı çalışmazsa başka bir şey yapmak istiyorsanız sorun değildir. Ancak, yalnızca hata mesajını görüntülemek ve komut dosyasını durdurmak istiyorsanız, buna ihtiyacınız yoktur, yakalanmayan istisna ölümcül bir hataya dönüşür. Veya site genelinde bir hata işleme ayarı da kullanabilirsiniz.
umarım yardımcı olur
PHP 7.1 ve sonrasında, bir catch bloğu dikey çizgi (|) karakterini kullanarak birden çok istisna belirtebilir. Bu, farklı sınıf hiyerarşilerinden farklı istisnalar aynı şekilde ele alındığında kullanışlıdır.
try {
// do something
} catch (Error | Exception $e) {
echo $e->getMessage();
}İstisnalar kasıtlı olarak kod tarafından fırlatma kullanılarak atılır, hatalar ... çok fazla değil.
Hatalar, genellikle ele alınmayan bir şeyin sonucu olarak ortaya çıkar. (GÇ hataları, TCP / IP hataları, boş referans hataları)
Size en alışılmadık bir hata kontrolü tartışması vermek niyetindeyim.
Yıllar önce bir dile çok iyi bir hata işleyici oluşturdum ve bazı isimler değişmiş olsa da, hata işleme prensipleri bugün aynıdır. Özel olarak oluşturulmuş çok görevli bir işletim sistemim vardı ve bellek sızıntısı, yığın büyümesi veya çökme olmadan her düzeyde veri hatalarını kurtarabilmeliydim. Bundan sonra, hataların ve istisnaların nasıl işlemesi gerektiği ve nasıl farklı oldukları konusundaki anlayışım var. Sadece, try catch'in iç kısımlarının nasıl çalıştığını anlamadığımı söyleyeceğim, bu yüzden bir ölçüde tahmin ediyorum.
Hata işleme kapakları altında gerçekleşen ilk şey, bir program durumundan diğerine atlamaktır. Bu nasıl yapılır? Ben buna ulaşacağım.
Tarihsel olarak, hatalar daha eski ve daha basittir ve istisnalar daha yeni ve biraz daha karmaşık ve yeteneklidir. Hatalar, onları şişirmeniz gerekene kadar iyi sonuç verir, bu da zor bir sorunu amirinize teslim etmeye eşdeğerdir.
Hatalar, hata numaraları gibi sayılar olabilir ve bazen bir veya daha fazla ilişkili dizeyle birlikte olabilir. Örneğin, bir dosya okuma hatası meydana gelirse, bunun ne olduğunu bildirebilir ve muhtemelen nazikçe başarısız olabilirsiniz. (Hay, eski günlerdeki gibi çökmekten bir adım ötede.)
İstisnalar hakkında sık sık söylenmeyen şey, istisnaların özel bir istisna yığını üzerinde katmanlı nesneler olduğudur. Bu, program akışı için bir dönüş yığını gibidir, ancak yalnızca hata denemeleri ve yakalamalar için bir dönüş durumu tutar. (Onlara ePush ve ePop derdim ve? Abort, ePop ve bu seviyeye kadar iyileşme sağlayan koşullu bir atıştı;
Yığının en altında, ilk arayan hakkında bilgi bulunur, dış denemenin ne zaman başlatıldığını bilen nesne, ki bu genellikle programınızın başlatıldığı zamandır. Üstüne üstlük ya da yığındaki bir sonraki katman, yukarı çocuklar ve aşağı ebeveynler olmak üzere, bir sonraki iç deneme / yakalama bloğunun istisna nesnesidir.
Bir deneyin içinde bir denerseniz, iç denemeyi dış denemenin üstüne yığmış olursunuz. İç denemede bir hata oluştuğunda ve ya iç yakalama bunu kaldıramazsa ya da hata dış denemeye atılırsa, kontrol, hatayı işleyip işlemediğini görmek için dış yakalama bloğuna (nesne) geçirilir, yani süpervizörünüz.
Bu hata yığınının gerçekten yaptığı şey, program akışını ve sistem durumunu işaretleyip geri yükleyebilmektir, başka bir deyişle, bir programın dönüş yığınını çökertmemesine ve işler ters gittiğinde başkaları için (veriler) işleri karıştırmamasına izin verir. Dolayısıyla, bellek ayırma havuzları gibi diğer kaynakların durumunu da kaydeder ve böylece yakalama işlemi tamamlandığında bunları temizleyebilir. Genel olarak bu çok karmaşık bir şey olabilir ve bu nedenle istisna işleme genellikle yavaştır. Genel olarak, bu istisna bloklarına epeyce durum girmelidir.
Yani bir dene / yakala bloğu, her şey karışırsa geri dönülebilecek bir durumu ayarlar. Bir ebeveyn gibi. Hayatlarımız altüst olduğunda, ebeveynimizin kucağına geri dönebiliriz ve onlar da her şeyi düzeltecek.
Umarım seni hayal kırıklığına uğratmamışımdır.
Set_error_handler () tanımlandıktan sonra, hata işleyicisi Exception'ınkine benzer. Aşağıdaki koda bakın:
<?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<- aslında, bu gerçekten doğru değil.E_ERRORveE_PARSEen yaygın iki kurtarılamaz hatadır (birkaç tane daha vardır), ancak dev'de göreceğiniz hataların büyük çoğunluğu kurtarılabilir (E_NOTICE,E_WARNINGve diğerleri). Ne yazık ki PHP'nin hata yönetimi tam bir karmaşa - her türlü şey hataları gereksiz yere tetikler (örneğin, dosya sistemi işlevlerinin büyük çoğunluğu). Genel olarak istisnalar "OOP yöntemi" dir, ancak ne yazık ki PHP'nin yerel OOP API'lerinden bazıları istisnalar yerine hatalar kullanır :-(