사용자 지정 예외 메시지 : 모범 사례

사용자 지정 예외 메시지 : 모범 사례

---

예외 메시지를 생성 할 때 유용한 디버깅 정보를 강제하는 데 얼마나 많은 노력을 기울여야하는지 궁금하십니까? 아니면 사용자가 올바른 정보를 제공 할 것이라고 믿거 나 정보 수집을 예외 처리기로 연기해야합니까?

많은 사람들이 다음과 같이 예외를 처리하는 것을 봅니다.

throw new RuntimeException('MyObject is not an array')

또는 많은 일을하지 않지만 예외의 이름을 변경하는 사용자 지정 예외로 기본 예외를 확장합니다.

throw new WrongTypeException('MyObject is not an array')

그러나 이것은 많은 디버깅 정보를 제공하지 않으며 오류 메시지와 함께 어떤 종류의 서식도 적용하지 않습니다. 따라서 두 개의 서로 다른 오류 메시지를 생성하는 정확히 동일한 오류로 끝날 수 있습니다. 예를 들어 "데이터베이스 연결 실패"대 "db에 연결할 수 없습니다."

물론 위쪽으로 거품이 발생하면 스택 추적이 인쇄되어 유용하지만 항상 알아야 할 모든 것을 알려주지는 않으며 일반적으로 발견하기 위해 var_dump () 문을 시작해야합니다. 무엇이 잘못되었고 어디에서 ... 괜찮은 예외 처리기로 다소 상쇄 될 수 있지만.

올바른 오류 메시지를 생성하기 위해 필요한 인수를 제공하기 위해 예외 발생자가 필요한 아래 코드와 같은 것을 생각하기 시작했습니다 . 나는 이것이 그것에 들어가는 방법이라고 생각하고 있습니다.

• 최소한의 유용한 정보를 제공해야합니다.
• 다소 일관된 오류 메시지 생성
• 예외 메시지에 대한 템플릿이 모두 한 위치 (예외 클래스)에 있으므로 메시지를 더 쉽게 업데이트 할 수 있습니다.

그러나 단점은 사용하기가 더 어렵고 (예외 정의를 찾아야 함) 다른 프로그래머가 제공된 예외를 사용하지 못하게 할 수 있다는 것입니다 ...

이 아이디어와 일관되고 유연한 예외 메시지 프레임 워크에 대한 모범 사례에 대한 의견을 듣고 싶습니다.

/**
* @package MyExceptions
* MyWrongTypeException occurs when an object or 
* datastructure is of the incorrect datatype.
* Program defensively!
* @param $objectName string name of object, eg "\$myObject"
* @param $object object object of the wrong type
* @param $expect string expected type of object eg 'integer'
* @param $message any additional human readable info.
* @param $code error code.
* @return Informative exception error message.
* @author secoif
*/
class MyWrongTypeException extends RuntimeException {
    public function __construct($objectName, $object, $expected, $message = '', $code = 0) {
        $receivedType = gettype($object) 
        $message = "Wrong Type: $objectName. Expected $expected, received $receivedType";
        debug_dump($message, $object);
        return parent::__construct($message, $code);
    }
}

....

/**
 * If we are in debug mode, append the var_dump of $object to $message
 */
function debug_dump(&$message, &$object) {
     if (App::get_mode() == 'debug') {
         ob_start();
         var_dump($object);
         $message = $message . "Debug Info: " . ob_get_clean();
    }
}

그런 다음 다음과 같이 사용됩니다.

// Hypothetical, supposed to return an array of user objects
$users = get_users(); // but instead returns the string 'bad'
// Ideally the $users model object would provide a validate() but for the sake
// of the example
if (is_array($users)) {
  throw new MyWrongTypeException('$users', $users, 'array')
  // returns 
  //"Wrong Type: $users. Expected array, received string
}

그리고 우리는 html 출력에 좋은 것을 만들기 위해 커스텀 예외 핸들러에서 nl2br 같은 것을 할 수 있습니다.

읽기 : http://msdn.microsoft.com/en-us/library/cc511859.aspx#

그리고 이와 같은 것에 대한 언급이 없으므로 아마도 나쁜 생각 일 것입니다 ...

---

나는 Krzysztof의 블로그 에 대한 조언을 강력히 권장하며 귀하의 경우에는 그가 사용 오류라고 부르는 것을 처리하려고 시도하는 것처럼 보입니다.

In this case what is required is not a new type to indicate it but a better error message about what caused it. As such a helper function to either:

1. generate the textual string to place into the exception
2. generate the whole exception and message

Is what is required.

Approach 1 is clearer, but may lead to a little more verbose usage, 2 is the opposite, trading a terser syntax for less clarity.

Note that the functions must be extremely safe (they should never, ever cause an unrelated exception themselves) and not force the provision of data that is optional in certain reasonable uses.

By using either of these approaches you make it easier to internationalise the error message later if required.

A stack trace at a minimum gives you the function, and possibly the line number, thus you should focus on supplying information that is not easy to work out from that.

---

I won't detract from the advise regarding Krzysztof's blog, but here is a dead-easy way to create custom exceptions.

Example:

<?php
   require_once "CustomException.php";
   class SqlProxyException extends CustomException {}

   throw new SqlProxyException($errorMsg, mysql_errno());     
?>

The code behind that (which I borrowed somewhere, apologies to whomever that was)

<?php

interface IException
{
    /* Protected methods inherited from Exception class */
    public function getMessage();                 // Exception message
    public function getCode();                    // User-defined Exception code
    public function getFile();                    // Source filename
    public function getLine();                    // Source line
    public function getTrace();                   // An array of the backtrace()
    public function getTraceAsString();           // Formated string of trace

    /* Overrideable methods inherited from Exception class */
    public function __toString();                 // formated string for display
    public function __construct($message = null, $code = 0);
}

abstract class CustomException extends Exception implements IException
{
    protected $message = 'Unknown exception';     // Exception message
    private   $string;                            // Unknown
    protected $code    = 0;                       // User-defined exception code
    protected $file;                              // Source filename of exception
    protected $line;                              // Source line of exception
    private   $trace;                             // Unknown

    public function __construct($message = null, $code = 0)
    {
        if (!$message) {
            throw new $this('Unknown '. get_class($this));
        }
        parent::__construct($message, $code);
    }

    public function __toString()
    {
        return get_class($this) . " '{$this->message}' in {$this->file}({$this->line})\n"
                                . "{$this->getTraceAsString()}";
    }
}

---

See How to Design Exception Hierarchies on the blog of Krzysztof Cwalina, a coauthor of "Framework Design Guidelines".

---

Never, ever trust a user to 'do the right thing', and include information for debugging. If you want information, you need to gather it yourself and store it somewhere where its accessible.

Also as stated, if it's hard(er) to do something, the users will avoid doing it, so again, don't depend on their goodwill and their knowledge of what they need to send.

This thinking implies a method by which you collect the information and log it, which implies using var_dump() somewhere.

Also, as said by Mark Harrison, a button which makes it easy to send an error message somewhere is fantastic for you and for the users. It makes it easy for them to report an error. You (as the recipient) get a lot of duplicates, but duplicate information is better than no information.

---

However much detail you add, be sure and either

• make it easy to cut and paste the whole thing, or
• have a button that will report the error for them

참고URL : https://stackoverflow.com/questions/628408/custom-exception-messages-best-practices