अपवादों में त्रुटियों को परिवर्तित करना: डिज़ाइन दोष?

Question

मैं हाल ही में कुछ कोड में आया था कि किसी भी PHP त्रुटियों को सामान्यीकृत अपवाद में बदलने के लिए कस्टम त्रुटि हैंडलर का उपयोग किया गया था। एक कस्टम अपवाद हैंडलर को भी परिभाषित किया गया था कि अगर यह एक विशेष त्रुटि कोड सीमा के भीतर था तो अपवाद लॉग करेगा। उदाहरण:

try 
{ 
    do_something(); 
} 
catch (AppException $exception) 
{ 
} 

कौन सा अर्थ है वास्तविक प्रोग्रामिंग त्रुटियों और "असाधारण" व्यवहार के बीच कोई फर्क नहीं है:

class AppException extends Exception 
{ 

} 

function error_handler($errno, $errstr, $errfile, $errline) 
{ 
    throw new AppException($errstr, $errno); 
} 

function exception_handler($exception) 
{ 
    $min = ...; 
    $max = ...; 

    if ($exception->getCode() >= $min && $exception->getCode() <= $max) 
    { 
     // log exception 
    } 
} 

set_error_handler('error_handler'); 
set_exception_handler('exception_handler'); 

$a[1]; // throws exception 

समस्या यह है कि मैं जैसी चीजों को देखा है।

... 

function my_function($param1, $param2) 
{ 
    // do something great 
} 

try 
{ 
    my_function('only_one_param'); 
} 
catch (AppException $exception) 
{ 
} 

कौन सा मुश्किल होता त्रुटियों और आवेदन के इंटरफ़ेस के डिजाइन समाप्त होता है: आगे खुदाई करने पर, मैंने कोड के कुछ हिस्सों कि विचार के आसपास जैसे कि PHP त्रुटियों का प्रतिनिधित्व किया "असाधारण" व्यवहार डिजाइन किए गए थे भर में आया था।

इस तरह की त्रुटियों को संभालने पर आपकी राय क्या है? क्या यह PHP की मूल त्रुटियों को अपवादों में बदलने लायक है? उपरोक्त स्थितियों में आप क्या करते हैं जहां इस विचार के आसपास कोडबेस बनाया गया है?

Answer 1

व्यक्तिगत रूप से, मैं यह हर समय करता हूं। फर्क सिर्फ इतना है कि मेरे error_handler समारोह में, मैं यह जांच लें कि त्रुटि एक E_NOTICE पहले है, और केवल फेंक अगर यह (मैं नोटिस लोग इन वैसे भी) नहीं है ...

मैं कुछ करने के लिए AppException बदल जाएगा है जो ErrorException बढ़ाता है ... कुछ ऐसा: PhpRuntimeErrorException extends ErrorException जो आप केवल PHP त्रुटियों के लिए उपयोग करते हैं ... कारण यह है कि यह अधिक पठनीय है (यह कहना आसान है कि PhpRuntimeErrorException को यह पता लगाने में आसान है कि इसे कहां फेंक दिया गया है)। अन्य कारण यह है कि ErrorException पैदा लाइन/फ़ाइल/etc जानकारी है, जहां यह कहीं और संग्रहीत नहीं किया जाएगा (के बाद से पश्व-अनुरेखन throw लाइन से शुरू होता है) ...

तो स्टोर करेगा है, तो आप "कोशिश कर सकते हैं "इस तरह कोड:

try { 
    $f = fopen('foo.bar', 'r'); 
    $ret = ''; 
    while ($data = fread($f)) { 
     $ret .= process($data); 
    } 
    fclose($f); 
    return ''; 
} catch (PHPRuntimeErrorException $e) { 
    throw new RuntimeException('Could not open file'); 
} catch (ProcessException $e) { 
    fclose($f); 
    throw new RuntimeException('Could not process data'); 
} 
return $ret; 

मैं अपना डिफ़ॉल्ट अपवाद हैंडलर 500 सर्वर त्रुटि पृष्ठ उत्पन्न करता हूं। ऐसा इसलिए है क्योंकि किसी भी अपवाद पकड़ा जाना चाहिए है, और अगर वे नहीं थे, यह वास्तव में एक सर्वर त्रुटि है ...

बस मेरे अनुभव और राय ...

Answer 2

पीएचपी समुदाय में इस बारे में कुछ बहस हुई है । मेरा मानना ​​है कि सामान्य सोच यह है कि आंतरिक PHP कार्यों द्वारा त्रुटियों को फेंक दिया जाता है, और कोडिंग समस्याएं हैं जिन्हें आपको वास्तव में ठीक करने की आवश्यकता है; जबकि अपवाद आपके एप्लिकेशन कोड द्वारा फेंकने वाली चीजें हैं जिन्हें आपको केवल 'हैंडल' करने की आवश्यकता हो सकती है।

हालांकि कुछ नए एसपीएल एक्सटेंशन (जो अधिक ऑब्जेक्ट उन्मुख होते हैं) उन चीजों के लिए अपवादों का उपयोग करते हैं जो पहले त्रुटियों को फेंक चुके थे, इसलिए कुछ ग्रे क्षेत्र है।

एक PHP कोर क्लास त्रुटि अपवाद - http://www.php.net/manual/en/class.errorexception.php भी है जो आपके कोड उदाहरण से उपयोग करने में थोड़ा आसान लग रहा है, यदि यह एक मार्ग है जिसे आप नीचे जाना चाहते हैं।

Answer 3

मैं अपवादों के नोटिस सहित सबकुछ बदलता हूं। अपवादों को सामान्य रूप से जारी रखने की अनुमति देने का कोई कारण नहीं है। अपरिभाषित चर या ऑफ़सेट? ये एक समस्या है।

https://github.com/KyleWolfe/PHPErrorNet