Benutzerdefinierte Ausnahmemeldungen: Best Practices

Sie fragen sich, wie viel Aufwand ich betreiben sollte, um beim Erstellen von Ausnahmemeldungen nützliche Debugging-Informationen zu erzwingen, oder sollte ich einfach darauf vertrauen, dass der Benutzer die richtigen Informationen bereitstellt, oder das Sammeln von Informationen an einen Ausnahmehandler verschieben?

Ich sehe viele Leute, die ihre Ausnahmen machen wie:

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

oder die Standardausnahmen mit benutzerdefinierten Ausnahmen erweitern, die nicht viel tun, aber den Namen der Ausnahme ändern:

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

Aber dies liefert nicht viele Debugging-Informationen … und erzwingt keinerlei Formatierung mit der Fehlermeldung. Sie könnten also mit genau demselben Fehler enden, der zwei verschiedene Fehlermeldungen erzeugt … zB “Datenbankverbindung fehlgeschlagen” vs “Konnte keine Verbindung zu db herstellen”

Sicher, wenn es nach oben sprudelt, wird der Stack-Trace gedruckt, was nützlich ist, aber es sagt mir nicht immer alles, was ich wissen muss, und normalerweise muss ich anfangen, var_dump () -Anweisungen abzuschießen, um es zu entdecken was schief gelaufen ist und wo … obwohl dies mit einem anständigen Ausnahmehandler etwas ausgeglichen werden könnte.

Ich fange an, über etwas wie den folgenden Code nachzudenken, wo ich benötigen der Werfer der Ausnahme, um die erforderlichen Argumente bereitzustellen, um die richtige Fehlermeldung zu erzeugen. Ich denke, dass dies der Weg sein könnte:

• Es muss ein Mindestmaß an nützlichen Informationen bereitgestellt werden
• Erzeugt etwas konsistente Fehlermeldungen
• Vorlagen für Ausnahmemeldungen an einem Ort (Ausnahmeklassen), sodass die Meldungen einfacher aktualisiert werden können …

Aber ich sehe den Nachteil darin, dass sie schwieriger zu verwenden sind (erfordert, dass Sie die Ausnahmedefinition nachschlagen) und daher andere Programmierer davon abhalten könnten, bereitgestellte Ausnahmen zu verwenden …

Ich hätte gerne einen Kommentar zu dieser Idee und Best Practices für ein konsistentes, flexibles Rahmenwerk für Ausnahmemeldungen.

/**
* @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();
    }
}

Dann verwendet wie:

// 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
}

und wir könnten so etwas wie ein nl2br in einem benutzerdefinierten Ausnahmehandler machen, um die Dinge für die HTML-Ausgabe angenehm zu machen.

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

Und so etwas wird nicht erwähnt, also ist es vielleicht eine schlechte Idee …

Ich empfehle dringend die Beratung auf Krzysztofs Blog und möchte anmerken, dass Sie in Ihrem Fall anscheinend versuchen, mit dem umzugehen, was er Nutzungsfehler nennt.

In diesem Fall ist kein neuer Typ erforderlich, um dies anzuzeigen, sondern eine bessere Fehlermeldung über die Ursache. Als solche Hilfsfunktion entweder:

1. Generieren Sie die Textzeichenfolge, die in die Ausnahme eingefügt werden soll
2. Generieren Sie die gesamte Ausnahme und Nachricht

Ist das, was erforderlich ist.

Ansatz 1 ist klarer, kann aber zu einer etwas ausführlicheren Verwendung führen, Ansatz 2 ist das Gegenteil und tauscht eine knappere Syntax gegen weniger Klarheit ein.

Beachten Sie, dass die Funktionen extrem sicher sein müssen (sie sollten niemals selbst eine unabhängige Ausnahme verursachen) und nicht die Bereitstellung von Daten erzwingen, die bei bestimmten vernünftigen Verwendungen optional sind.

Durch die Verwendung eines dieser Ansätze erleichtern Sie es, die Fehlermeldung später bei Bedarf zu internationalisieren.

Ein Stack-Trace gibt Ihnen zumindest die Funktion und möglicherweise die Zeilennummer an, daher sollten Sie sich darauf konzentrieren, Informationen bereitzustellen, die daraus nicht leicht zu ermitteln sind.

Ich werde nicht von den Ratschlägen zu Krzysztofs Blog ablenken, aber hier ist eine kinderleichte Möglichkeit, benutzerdefinierte Ausnahmen zu erstellen.

Beispiel:

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

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

Der Code dahinter (den ich mir irgendwo ausgeliehen habe, entschuldige denjenigen, der das war)

<?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()}";
    }
}

Sehen So entwerfen Sie Ausnahmehierarchien auf dem Blog von Krzysztof Cwalina, einem Co-Autor von “Framework Design Guidelines”.

Vertrauen Sie niemals einem Benutzer, dass er „das Richtige tut“, und fügen Sie Informationen zum Debuggen hinzu. Wenn Sie Informationen wünschen, müssen Sie sie selbst sammeln und an einem Ort aufbewahren, an dem sie zugänglich sind.

Wie bereits erwähnt, wenn es schwierig ist, etwas zu tun, werden die Benutzer es vermeiden, also verlassen Sie sich auch hier nicht auf ihren guten Willen und ihr Wissen darüber, was sie senden müssen.

Dieses Denken impliziert eine Methode, mit der Sie die Informationen sammeln und protokollieren, was die Verwendung von var_dump() irgendwo impliziert.

Außerdem ist, wie von Mark Harrison gesagt, eine Schaltfläche, die es einfach macht, irgendwo eine Fehlermeldung zu senden, fantastisch für Sie und die Benutzer. Es macht es ihnen leicht, einen Fehler zu melden. Sie (als Empfänger) erhalten viele Duplikate, aber doppelte Informationen sind besser als keine Informationen.

Egal, wie viele Details Sie hinzufügen, seien Sie sicher, und beides

• Machen Sie es einfach, das Ganze auszuschneiden und einzufügen, oder
• haben eine Schaltfläche, die den Fehler für sie meldet