[Chr!s]

Tag,
da in der Forenbeschreibung "zur allgemeinen Anwendungsmodellierung" steht, hab ich meine Frage hier reingestellt. Sollte das dennoch falsch sein, verschiebt es einfach.

Ich würde mal gerne Meinungen zum Management bzw. zur Vergabe von Errorcodes hören. Folgenden Ansatz habe ich mir überlegt:
Es gibt mehrere Arten von Fehlern im System, einmal Klasseninterne Fehler. Diese haben eine niedrige Priorität und werden dem User als ganz normale Fehlermeldung präsentiert.
Beispiel:

PHP-Code:

<?php
private function handleUploadedFile() {
    if( $this -> isNoValidFileExentsion() ) {
        return ErrorHandler::getErrorcode('noValidFileExteision');
    }

    if( $this -> fileIsTooBig() ) {
        return ErrorHandler::getErrorcode('fileIsTooBig');
    }
}
?>

(mir sind gerade keine besseren Methodennamen eingefallen, aber das dient ja nur zur Veranschaulichung).

Und dann gibt es aber noch die Core-Fehler:

PHP-Code:

<?php
class Configuration {
    private $aConfiguration = array();

    public static function loadMainConfiguration() {
        if( !file_exists('configuration/configuration.ini') ) {
            // Main configuration was not found, terminate the application
            throw new FileNotFoundException('The main configuration-file could' .
                'not have been found', 12345);
        }

        // is_readable() ...

        self::$aConfiguration = parse_ini_file('configuration/configuration.ini');
    }
}

class Controller {
    private function startUp() {
        try {
            Configuration::loadMainConfiguration();
        }
    
        catch (FileNotFoundException $oException) {
            ErrorHandler::terminate($oException -> getMessage(),
                                    $oException -> getCode());
        }
    }
}
?>

Der wird einem User auch angezeigt, allerdings (da er eine höhere Priorität besitzt, oder besser, der Fehler wiegt schwerer) mit einem "Kritischer Fehler aufgetreten"-Label, einem Errorcode (evtl bei einem UserFrontend auch mit Link zum Kontakt mit dem Admininstrator) und der Message, die zu dem Fehlercode gehört (aus der Datenbank).

Wie vergebe ich nun am besten solche Errorcodes, um sie gut handzuhaben? Klar könnte ich sie von 1-1000 durchnumerieren und allesamt in einer Datenbank inkl. Fehlermeldung abspeichern, aber das wäre mir irgendwie zu unkategorisiert. Ich hatte schon mal einen Ansatz wie "00-123" wobei die ersten Zahlen für den Bereich (00 - Controller, 01 von mir aus Model usw) stehen, und die restlichen Zahlen für den relevanten Fehler innerhalb des Bereiches. Das würde sich zwar dann mit dem IntegerTyp des Exception::code beissen, aber ich könnte ja eine eigene xyzException::getErrorcode() schreiben (anstatt von ::getCode(), die ist nämlich final und somit nicht überschreibbar).

Ich schau mir grad bei Google die Trefferergebnisse mit error codes an..
Dort findet sich am häufigsten die Variante:
12345678 .. find ich auch eigentlich ganz schön, z.B.
01000001 = invalid username
01000002 = invalud password
01000003 = user does not exist
...
02000001 = xyz ..

Auch wenn 8 Zeichen recht viel sind, 4 oder 6 würden auch schon reichen.

Dennoch würde mich interessieren: Wie handhabt ihr solche Fehler? Macht ihr euch überhaupt solchen Aufwand und wenn ja, wie? Oder was würdet ihr vorschlagen?
Bin mal gespannt auf eure Vorschläge.

[WarrenFaith]

Also ich persönlich finde es gut, wenn man mit Fehlercodes arbeitet, denn dann kann man in der Doku wesentlich ausführlicher darauf eingehen und Hilfestellungen liefern. Ne Art Fehlercode-FAQ.
Businesslogikfehler sollte man nicht mit Errorcodes versehen. Lediglich intern vielleicht, damit man besser lokalisieren kann. Also Businessfehler sind Meldungen wie "Logindaten fehlerhaft" aber das steht hier ja nicht zur Diskussion, nur der vollständigkeitshalber mal erwähnt.

Die Art der Kategorisierung ist natürlich eine gute Idee. Konflikte mit dem Integer kann man einfach vermeiden indem man die Kategorie mit 10, 20, 21 etc benennt und nicht durch ein Seperator teilt. Warum nicht einfach definieren, dass die ersten 2 oder 3 stellen die Kategorie symbolisieren und alles dahinter der normale Errorcode ist.

Ich hab leider selbst noch nicht wirklich mit Fehlercodes gearbeitet, aber so würde ich das schon machen.

[Chr!s]

Meldungen wie "Logindaten fehlerhaft" aber das steht hier ja nicht zur Diskussion

Doch, diese hab ich auch gemeint. In meinem ersten Beispiel hab ich ja ein Upload Modelliert - auch hier soll ein Fehlercode existieren (der Vollständigkeit halber), die alle, wie du schon erwähnt hast, in einem Fehlercode-FAQ zusammengefasst werden. Diese werden später auch dann unter der FehlerID in einem FEhlerlog gespeichert, im Fehler-FAQ werden die entsprechenden Erläuterungen für den Administrator der Anwendung bereitstehen.

[FloB]

Ich würds so machen:
Erste Ziffer bezeichnet Bereich:
1 - User relevant error (Falsche Eingaben des Users)
2 - script error (von deinen Scripten erzeugte, "persöhnliche" Fehler; z.B. Abfrage, ob ein Wert existiert, wenn nicht -> Fehler)
3 - runtime error (PHP-Fehler)
4 - filesystem error (z.B. nicht vorhandene Datei)
5 - db error
6 - ...
Hinweis: Erste Ziffer sollte nicht 0 (null) sein, da es sonst Probleme mit dem Integer-Wert gibt (wird abgeschnitten).

2. Ziffer:
Genauere Unterteilung, z.B. User-Error:
0 - fehlende Angabe
1 - ungültige / unzureichende Angabe
2 - falsche Angabe (z.B. CAPTCHA nicht richtig)
3 - ...

Weitere Ziffern:
Genaue Fehlerbeschreibung, bei DB-Abfragen kann z.B. direkt der SQL-Errorcode geliefert werden (links mit nullen auffüllen!).
Bei User-Angaben kann z.B. eine eindeutige ID für ein Feld angegeben werden, etc.


Kann man alles frei interpretieren . Ist mit auch nur gerade eingefallen, also nicht unbedingt geistreich ..

Aber nach Bereichen sollte es auf jeden Fall eingeteilt sein, zwecks besserer Debug-Möglichkeit.

[Chr!s]

Ich denke es ist auch wichtig, welche Ausmaße die Anwendung annimmt. Wenn es relativ klein ist, dann sollten 2stellige IDs reichen (XY : X für Bereich, Y für Fehler), wird das Projekt größer, brauch ich eben mehr (4,5,6 stellig, evtl auch mit schärferer Unterteilung in X Y un Z) .. nehm ich solche Integer Werte, kann ich auch bequem mit der Exception::getCode() darauf zugreifen.

Danke für eure Antworten.

[WarrenFaith]

Ich bin der Meinung, dass Errorcodes nichts in einer Businessmeldung zu tun haben.
Ich mag es nicht, wenn dort steht: "Error 40392: Logindaten fehlerhaft."

Es ist um einiges wichtiger, dass die Optik stimmt, denn es ist bei weitem nicht jeder User/Nutzer der Software so bewandert, dass er alleine den "Errorcode" als Begriff versteht. Ich denke da immer an meine Eltern...

Lediglich für die Lokalisierung kann man dann mit Codes arbeiten. Aber ich glaube ich wiederhole mich da.

[Chr!s]

Natürlich wird dem User das entsprechende View gezeigt, was auch optisch zur Seite passt, ganz klar. Aber der Error 40392 soll geloggt werden, wenn auch Logindaten fehlerhaft jetzt nicht das ist, was man unbedingt braucht - aber das kommt ja auf die Anwendung drauf an und den Fehler drauf an.

[FloB]

Hm, ich würde sagen, dass die Fehlercodes die gleiche Länge haben sollen. MySQL wirft Fehlercodes AFAIK mit bis zu 5 Stellen aus. Daran sollte man sich dann halten und ein einheitliches System aufbauen.

[mepeisen]

Zitat von FloB

Hm, ich würde sagen, dass die Fehlercodes die gleiche Länge haben sollen. MySQL wirft Fehlercodes AFAIK mit bis zu 5 Stellen aus. Daran sollte man sich dann halten und ein einheitliches System aufbauen.

Wo wäre da der Nutzen? Man unterscheidet dabei meiner Meinung nach, da man sonst zuviele Abhängigkeiten hat. Wenn du technische Fehler von MySQL und Konsorten mit den eigenen Fehlercodes "verschmelzen" willst, bist du irgendwie immer auch davon abhängig, dass keine Überschneidungen zustande kommen. Sonst gibt es unnötige Verwirrung, wenn du die gleiche Fehlercodes vergibst, die von einem anderen System bereits vergeben sind.

Also eigene Fehlercodes und Fehlercode #1000102 "MySQL-Fehler" zeichnet sich dadurch aus, dass er weitergehende Informationen beinhalten kann, nämlich die MySQL-internen Fehlerinformationen.

Grundsätzlich aber würde ich die Aufmerksamkeit nochmal auf das erste Beispiel lenken wollen. Denn da sollte vielleicht noch einmal drüber nachgedacht werden. Es gibt grundsätzlich zwei technische Arten von Fehlern. Die erste Fehlerart sind Rückgabewerte und die zweite Fehlerart sind Exceptions. Diese beiden unterscheiden sich insoweit, dass sich Kategorie a) ignorieren lässt und Kategorie b) nicht so ohne weiteres. Wer sauber programmiert, den stört das nicht, ob ein Fehler als Exception zurückgegeben wird oder als Rückgabewert. Aber Entwickler sind von Haus aus faul. Irgendwie klingt das unsauber, beides mischen zu wollen. Ich mische das eigentlich nie. Und ich gebe detailliertere Fehlermeldungen immer als Exception zurück. Das ist jedoch Geschmackssache. Bei mir gibt es als Rückgabewert immer ein true oder false zum Prüfen, ob was erfolgreich war, nie mehr.

Die Vergabe der internen IDs geschieht bei mir eigentlich immer durch eine zweistufige Kombination, wie es oben angeklungen war. Die Präsentation der Fehler in der UI-Schicht wird davon getrennt. Also erst die UI-Schicht weiss, wie sie mit einem Fehler verfahren soll und ob sie Fehler #1000102 aus Sicherheitsgründen nur als Text "Allgemeiner Datenbankfehler" darstellt...

[FloB]

Wenn ich also jetzt die Zuordnung habe: #59xxxx (4-stelliger Fehlercode), dann kann ich in meiner Error-Handling-Funktion einfach die 59 rausschneiden, und den entsprechenden Fehlercode weiterbearbeiten, evtl. einfach den Fehler-String zur entsprechenden ID holen.

Also, mMn am besten vorhandene Fehlercode-Systeme nutzen und diese entsprechend erweitern (eben per Präfix), und für Bereiche, in denen es kein vorhandenes Fehler-ID-Management gibt, eins selbst entwerfen.

Und warum gleiche Länge? Einfach wegen der Übersicht. Ein einheitliches Schema sorgt dafür, dass es keine Verwirrung gibt.

Ich würde einfach folgendes Schema empfehlen:

1. Ziffer: Bereich
2-5. Ziffer: Fehlercode, bei DB-Fehlern die gegebene ID, bei allen anderen (nicht vorhandenen) eigenes Fehlergerüst verwenden

Man könnte den 2. Bereich auch variabel gestalten, nur dann wird das ganze unübersichtlich, und man braucht zusätliche Zeilen Code. Außerdem: Wenn man den 2. Bereich intern nochmal unterteilt, wird man wohl doch genug mögliche Fehler finden, um alle 4 Zeichen auszunutzen

[mepeisen]

Zitat von FloB

Und warum gleiche Länge? Einfach wegen der Übersicht. Ein einheitliches Schema sorgt dafür, dass es keine Verwirrung gibt.

Wobei Das mit dem 5stellig dann aber nicht immer passt, da beispielsweise DB/2 auf 4stellige Codes setzt. PHP selbst hat da keine Vorgaben bzw. einfache Numerierungen. Und es gibt noch eine Reihe, die alphanumerische Fehlercodes produzieren (was MySQL im Grunde auch macht), die nicht 5stellig sind. Ich sehe den Sinn bei sowas nicht. Aber das mag jeder so sehen, wie er will
In meinen Augen ist es völlig egal, wieviel Ziffern man als Fehlercode definiert. Hier gibt es keine einheitlichen Systeme. Und MySQL-Fehler u.ä. gehören dann entsprechend gekapselt.

[FloB]

Wegen der Kapselung: Wie gesagt, warum nicht das vorhandene System nehmen?

Also, MySQL gibt auch nur max. 4-stellige Codes aus, hatte was andres in Erinnerung.

Und auffüllen ist ganz einfach: mit str_pad() (ist zwar ne Funktion für andere Typen, tuts aber auch )

Ich mein halt nur: Je einheitlicher das Schema, desto besser kann es von einem Menschen gelesen werden. Wenn du jetzt eine Log hast, in der steht 591007, dann weist du: Aha, Datenbankfehler, MySQL-Code 1007 bedeutet: Konnte Datenbank nicht erzeugen, weil sie schon existiert.

So einfach ist das. Noch fragen?

Aber jedem Tierchen sein plaisierchen

[mepeisen]

Ich dachte, es soll auch hinterher 591007 auf dem Bildschirm ausgegeben werden?!?!? Das würde ich nicht wollen. Den Benutzer sollte (auch aus Sicherheitsgründen) nicht unbedingt haargenau interessieren, weswegen das MySQL da meckert. Ihm schickt es zu wissen, dass es putt ist. Für den einen ist es Geschmackssache, für mich sollte man sowas mit berücksichtigen, dass man eventuell die Fehler nicht zu hundertprozent auf dem Bildschirm darstellt, wie sie in der Log-Datei auch landen. Mit anderen Worten: Bei Fehlern macht es für mich Sinn, auch sowas wie eine Kapselung zu berücksichtigen.

Zum Suchen finde ich es persönlich schöner, wenn in einer Log zwischen 50.000 Meldungen einmal was von SQL-CODE steht. Dann finde ich die SQL-Fehler auf Anhieb. Liegt vielleicht daran, dass ich von unseren Projekten aber auch immer pro Tag meistens 100 MB Log-Dateien gewohnt bin und dann mit irgendwelchen kryptischen Zahlencodes nicht zurande komme, wenn ich mal was suche. Und unsere User wollen nicht komische Fehlercodes sehen, sondern die wollen lesen "Rechenzentrum ist putt. Anwendung geht nitt. Bitte am Telefon meckern". Oder sowas in der Art *g*

[FloB]

Ja klar, natürlich kommen die Nachrichten nicht zum Endnutzer . Hatte ich aber auch nie gesagt .. was mein Anliegen war: Transparenz für den Entwickler. Und wenn jetzt im Log 59xxxx steht oder SQL-CODE, ist mir das egal, ich lass mir eh alle Fehler ordentlich sortieren und bekomm dann mindestens zwei Spalten: Fehlerbereich (SQL) und Fehlernummer. Damit kann man dann weiterarbeiten .

Aber du sagst richtig: Der normale Endnutzer hat keine Ahnung, was die Fehlernummer bedeutet und will Klartext hören. Am besten leicht verständlich. "Interner Fehler" ist manchmal etwas zu ungenau für die Nutzer; aber die sollen ja auch nicht debuggen .

Fazit: Transparenter Fehlercode für Entwickler, für Endnutzer einfache Meldung.