[PHP5] Error handling: Eén error class of meerdere?

[Mithrandir]

Ik zit een beetje te stoeien met PHP5 de laatste tijd. Nu vraag ik me af hoe ik de error handling moet aanpakken.

Op de site van Zend staat het volgende:

[quote=www.zend.com]
Subclassing Exception
There are two clear reasons why you might want to subclass Exception. These are:

• To provide specialized functionality within your subclass
• To distinguish one error type from another as a service to client code.


Dit snap ik wel, maar in hoe verre is het handig om dit door te voeren?

Ik vind het volgende namelijk redelijk loos om te doen:

PHP:

class FileNotFoundException extends Exception{};
class NumberFormatException extends Exception{};
class UserInputException extends Exception{};
... etc

Extra functionaliteit inbouwen kan ik begrijpen. Bijvoorbeeld een functie om een error mooi weer te geven (bijvoorbeeld in een template).

In hoeverre is het handig om toch verschillende errorclasses te maken, als je de error ook kunt weergeven in de errorstring?

[NMe]

Kun je niet gewoon één errorclass maken, met één functie, die een bepaalde string laat zien? Om nou voor elke exception een eigen implementatie van een errorfunctie te maken is idd nogal loos, en ik vind dit niet echt passen in een OOP omgeving.

[Skaah]

Als het praktisch is, kun je misschien een uitbreiding maken.

Bijvoorbeeld een MySQL error class die automagisch mysql_error() en mysql_errorno() toont.

Anders heeft het weinig zin.

[Verwijderd]

Ik vind 1 class per error juist wel mooi, ipv. zomaar strings doorgeven

[NMe]

Verwijderd schreef op 15 september 2004 @ 16:21:
Ik vind 1 class per error juist wel mooi, ipv. zomaar strings doorgeven

Het mooie van classes is juist dat je per object maar 1 keer de code hoeft te schrijven... Desnoods maak je meerdere functies binnen één klasse, of meerdere implementaties van dezelfde functie, die je dan overload ofzo (als dat mogelijk is in PHP). Maar meedere klassedefinities voor zoiets simpels als dit lijkt me een slecht plan.

[Mithrandir]

NMe84 schreef op 15 september 2004 @ 16:26:
[...]

Het mooie van classes is juist dat je per object maar 1 keer de code hoeft te schrijven... Desnoods maak je meerdere functies binnen één klasse, of meerdere implementaties van dezelfde functie, die je dan overload ofzo (als dat mogelijk is in PHP). Maar meedere klassedefinities voor zoiets simpels als dit lijkt me een slecht plan.

Je hoeft de code nog steeds maar één keer te schrijven, maar dit keer met een apart error class. Dat geeft ook voor bijvoorbeeld localisation voordelen.

Door bijvoorbeeld een FilePermissionException te throwen in plaats van een FileInclusionError, kan er veel beter gedebugd worden. Je hoeft dat dan namelijk niet meer direct door te geven in de error string. Daar is dan namelijk echt nuttige informatie verzamelbaar

[ Voor 5% gewijzigd door Mithrandir op 15-09-2004 16:42 ]

[Orphix]

Mithrandir schreef op 15 september 2004 @ 16:00:
In hoeverre is het handig om toch verschillende errorclasses te maken, als je de error ook kunt weergeven in de errorstring?

Zoals zend al zegt: "To distinguish one error type from another as a service to client code. "

Ik wil als gebruiker van jouw code niet te maken krijgen met een FileNotFoundException wanneer ik bijvoorbeeld een Mithrandir->ResolveDNS(..) methode aanroep. Ik verwacht dan een exception met een hogere abstractie, zoiets als DNSException, met daarin (als inner-exception) de FileNotFoundException, voor meer details.

Tevens zijn er situaties bedenkbaar waarbij een NumberFormatException genegeerd kan worden, en een UserInputException niet. Dit kan je prima regelen door je in je catch(..) statements op de class type te filteren.

[Mithrandir]

Orphix schreef op 15 september 2004 @ 16:43:
[...]

Zoals zend al zegt: "To distinguish one error type from another as a service to client code. "

Ik wil als gebruiker van jouw code niet te maken krijgen met een FileNotFoundException wanneer ik bijvoorbeeld een Mithrandir->ResolveDNS(..) methode aanroep. Ik verwacht dan een exception met een hogere abstractie, zoiets als DNSException, met daarin (als inner-exception) de FileNotFoundException, voor meer details.

Tevens zijn er situaties bedenkbaar waarbij een NumberFormatException genegeerd kan worden, en een UserInputException niet. Dit kan je prima regelen door je in je catch(..) statements op de class type te filteren.

Daar kan ik me wel in vinden. De userInputException was overigens even heel snel als voorbeeldje neergezet.

Waar ik een beetje bang voor ben is dat de code een gigantsiche warboel van try, throw en catch statements wordt...

[gorgi_19]

Mithrandir schreef op 15 september 2004 @ 16:48:
[...]


Daar kan ik me wel in vinden. De userInputException was overigens even heel snel als voorbeeldje neergezet.

Waar ik een beetje bang voor ben is dat de code een gigantsiche warboel van try, throw en catch statements wordt...

Heb je dan zo veel 'kritieke' situaties, waarbij normale errorhandling niet voldoende is? Exceptions horen niet gebruikt te worden voor normale condities / checks, alleen uitzonderingen.

[Verwijderd]

gorgi_19 schreef op 15 september 2004 @ 16:50:

Heb je dan zo veel 'kritieke' situaties, waarbij normale errorhandling niet voldoende is? Exceptions horen niet gebruikt te worden voor normale condities / checks, alleen uitzonderingen.

* fladder agrees

En subclassen van excepties is nuttig als je de verschillende excepties op verschillende plekken of op verschillende manieren wilt afhandelen (en kan dus zeker WEL nuttig zijn, NMe84).

[Mithrandir]

gorgi_19 schreef op 15 september 2004 @ 16:50:
[...]

Heb je dan zo veel 'kritieke' situaties, waarbij normale errorhandling niet voldoende is? Exceptions horen niet gebruikt te worden voor normale condities / checks, alleen uitzonderingen.

Om daar even op verder te gaan, hoe moet je die normale checks dan afhandelen? Op welk moment behoor je dan wél exceptions te genereren? Zijn daar 'vuistregels' voor?

[uitleg]
Waarom zou je bijvoorbeeld bij het checken van userinput geen exceptions kunnen gooien? In het catch blok kun je dan een errorpagina weergeven waarin de gebruiker iets opnieuw kan invullen bijvoorbeeld.
Of kan dat dan beter meteen gedaan worden?

[ Voor 32% gewijzigd door Mithrandir op 15-09-2004 17:20 ]

[Verwijderd]

Kweenie of ik het goed omschrijf, want wel of niet excepties gebruiken gaat eigenlijk vanzelf bij mij... intuitie? Maargoed in principe gooi je excepties als je (en je is hier en bepaald object) een bepaalde taak uitvoert maar de foutafhandeling aan de gebruiker (een ander object dus) wilt overlaten, omdat dit applicatiespecifiek is.

Zelf vind ik excepties ook erg handig als ik een reeks handelingen achter elkaar moet uitvoeren die afhankelijk van elkaar zijn maar zodra 1 van die handelingen fout gaat moet ie eruit klappen. Dat kan ook met een heleboel testen op nullpointers maar dat werkt gewoon veel minder makkelijk.

Normale checks kunnen ook weer in combinaties met excepties trouwens

public float deel(float deler, float noemer) throws DelingDoorNulException
{
if( noemer == 0 )
throw DelingDoorNulException();
return deler/noemer;
}

Het is aan degene die deel(..) aanroept om aan de hand van die exception een warning op het scherm te geven.

[ Voor 24% gewijzigd door Verwijderd op 15-09-2004 18:09 ]

[Mithrandir]

Dus er worden eerst een aantal exceptions gegooid. Als die opgelost kunnen worden dan moet het programma gewoon door gaan met draaien. Als ze niet opgelost kunnen worden dan moet het systeem stoppen met uitvoering en een error gooien (al dan niet naar de gebruiker/email/logbestand/etc)?

[Mithrandir]

A word about checked exceptions
1) The great value of exceptions is the unification of error reporting: a standard mechanism by which to report errors, rather than the popourri of ignorable approaches that we had in C (and thus, C++, which only adds exceptions to the mix, and doesn't make it the exclusive approach). The big advantage Java has over C++ is that exceptions are the only way to report errors.

2) "Ignorable" in the previous paragraph is the other issue. The theory is that if the compiler forces the programmer to either handle the exception or pass it on in an exception specification, then the programmer's attention will always be brought back to the possibility of errors and they will thus properly take care of them. I think the problem is that this is an untested assumption we're making as language designers that falls into the field of psychology. My theory is that when someone is trying to do something and you are constantly prodding them with annoyances, they will use the quickest device available to make those annoyances go away so they can get their thing done, perhaps assuming they'll go back and take out the device later. I discovered I had done this in the first edition of Thinking in Java:

Java:

} catch (SomeKindOfException e) {}

And then more or less forgot it until the rewrite. How many people thought this was a good example and followed it? Martin Fowler began seeing the same kind of code, and realized people were stubbing out exceptions and then they were disappearing. The overhead of checked exceptions was having the opposite effect of what was intended, something that can happen when you experiment (and I now believe that checked exceptions were an experiment based on what someone thought was a good idea, and which I believed was a good idea until recently).

When I started using Python, all the exceptions appeared, none were accidentally "disappeared." If you *want* to catch an exception, you can, but you aren't forced to write reams of code all the time just to be passing the exceptions around. They go up to where you want to catch them, or they go all the way out if you forget (and thus they remind you) but they don't vanish, which is the worst of all possible cases. I now believe that checked exceptions encourage people to make them vanish. Plus they make much less readable code.

In the end, I think we must realize the experimental nature of exceptions and look at them carefully before assuming that everything about exceptions in Java are good. I believe that having a single mechanism for handling errors is excellent, and I believe that using a separate channel (the exception handling mechanism) for moving the exceptions around is good. But I do remember one of the early arguments for exception handling in C++ was that it would allow the programmer to separate the sections of code where you just wanted to get work done from the sections where you handled errors, and it seems to me that checked exceptions do not do this; instead, they tend to intrude (a lot) into your "normal working code" and thus are a step backwards. My experience with Python exceptions supports this, and unless I get turned around on this issue I intend to put a lot more RuntimeExceptions into my Java code.

Toen ik dit las, zat ik me weer even af te vragen waarom die exceptions er zijn, en of ze wel echt iets toevoegen aan de scripttaal PHP.

Wat zijn jullie gedachtes hierover?

[eamelink]

Mithrandir schreef op 19 september 2004 @ 22:38:
[...]


Toen ik dit las, zat ik me weer even af te vragen waarom die exceptions er zijn, en of ze wel echt iets toevoegen aan de scripttaal PHP.

Wat zijn jullie gedachtes hierover?

PHP zal meer serieuze dingen moeten implementeren om enigszins bij te kunnen blijven met het .net platform.

Volgens mij moeten ze dat niet doen, en gewoon blijven wat ze zijn ; een oersimpele, makkelijk te leren scripttaal.

[SchizoDuckie]

Waarom zo'n moeilijk error handling systeem in iets wat gewoon een verzameling scripts blijft? Een error is toch een error, en je kan met een debug_backtrace wel aangeven waar ie vandaankomt.

[not-known]

eamelink schreef op 19 september 2004 @ 22:46:
[...]


PHP zal meer serieuze dingen moeten implementeren om enigszins bij te kunnen blijven met het .net platform.

Volgens mij moeten ze dat niet doen, en gewoon blijven wat ze zijn ; een oersimpele, makkelijk te leren scripttaal.

Nou ja, ze zijn inmiddels op weg om net als bijv. in Perl ook gewoon executeerbare scriptjes te kunnen maken die je kan draaien onder CLI. Daarvoor zijn zulke dingen wel handig om te gebruiken aangezien de time to live van het script hoger is en je vaak veel meer objecten zal gebruiken, dan in een standaard web script.
Ik ben ook bezig met een wat groter script in php wat onder CLI draait en het is leuk om er mee te spelen moet ik zeggen. De meeste dingen die ik er in gebruik zal je in een normaal script nooit toepassen. Dat moet snel uitgevoerd worden op de webpage, dus die extra ballast is alleen maar lastig.
Maargoed, misschien is het voor beginnende scripters een wat grotere brug geworden om te nemen, aangezien het doel van bepaalde zaken in php nou niet echt duidelijk word.

[drm]

Ik denk dat de fout die Zend maakt bij dit soort dingen is dat ze de eenvoud van PHP min of meer gaan vervuilen met technieken die in andere talen/platforms al ingebed zijn en daar voordelen bieden. Het probleem dat vervolgens bij PHP optreedt is dat de verbanden tussen de code die je zelf schrijft en de engine die eronder hangt steeds vager worden. Daarmee bedoel ik: waarom worden notices en warnings niet ook Exceptions? Gooi dan ook meteen de set_error_handler toestanden overboord, en zorg dat je het complete concept van Exceptions in de engine verwerkt.

Hetzelfde is feitelijk aan de hand met "OO" in PHP4; het werkt eigenlijk niet helemaal, maar "ach, dat OO blijkt zo goed te werken bij C++, Java (etc...), eigenlijk kunnen we dan met PHP niet achterblijven".

Da's imo een beetje het nadeel van dit soort dingen in een taal/platform als PHP. De concepten worden ingevoerd op een moment dat ze binnen de taal/specificaties eigenlijk nog niet volwassen zijn. (en imo moet je ze dan ook gewoon nog niet gebruiken waar het niet direct voordelen biedt)