Exception - Seite 2

nikosch · 09.09.2008, 14:09

Zitat:

Es musst entweder eine andere Lösung geben, oder ich muss die Werte ganz einfach auslesen, und einzelnd an das neue Object weitergeben. Grml

Du solltest Dir die Mühe machen. Ein System sollte m.E. immer dafür offen bleiben, auch herkömmliche Exceptions zu verarbeiten (die vielleicht später ein Entwickler werfen lässt, ohne dass Du wieder nachbearbeiten kannst).

Higidi · 09.09.2008, 14:46

Zitat:

Zitat von nikosch

Du solltest Dir die Mühe machen. Ein System sollte m.E. immer dafür offen bleiben, auch herkömmliche Exceptions zu verarbeiten (die vielleicht später ein Entwickler werfen lässt, ohne dass Du wieder nachbearbeiten kannst).

Ich baue mir lediglich die Möglichkeit dem Exception Object auch werte zu schenken, von einem Exception Wert

, schließe damit aber den herkömmlichen Weg nicht aus

Aber anscheinend gibt es ja keinen "schöneren" Weg, aber bin immer offen für neues.

nikosch · 09.09.2008, 14:54

Ich meine das anders: Wenn später wieder jemand throw Exception ('xy') schreibt, sollte das doch trotzdem über einen einheitlichen Handler verarbeitet werden (wenn vielleicht auch eingeschränkt). Deshalb halte ich die Anpassung der handleExceptions für originale Exception für sinnvoller, als allen Code mit neuen Exceptionaufrufen zu versehen.

David · 10.09.2008, 10:38

Das Ding soll doch eh nur unbehandelte Toplevel Exceptions (die hoffentlich eh selten sind) auffangen. Was der Benutzer in so einem Fall braucht, ist die Anzeige "Tut uns furchtbar leid. Der Fehler wurde vermerkt und wird schnellst möglich bearbeitet". Die Detailangaben wandert ins bug tracking. Denn das ist eine unbehandelte toplevel exception: ein bug. Eventuell bekommt der Benutzer noch eine tracking id angezeigt - die aber nichts mehr mit der Exception selbst zu tun hat.
Ich würde einer Exception-Klasse keine show(int level)-Methode verpassen. Was käme dann als nächstes? callCellphone() ?

toString()/getMessage() sollte voll ausreichen.

Higidi · 10.09.2008, 13:29

Huhu David,

danke ja, ich habe mir mitlerweile gleiches gedacht. ich werde es nun auch so bzw. fast so ähnlich machen und ich glaube dank deinem Post ist mir die eigentlich Funktionalität der set_exception_handle Option von PHP nochmal klar geworden. Aus der Sicht hatte ich das bis jetzt noch gar nicht betrachtet, aber das macht ja auch Sinn.
Ich danke euch auf jeden Fall allen, die sich bemüht haben mir zu helfen und ich hoffe ich kann gleiches mal zurückgeben.
Wünsche euch allen eine schöne Woche und viel Spaß beim Programmieren!

Grüße

Daniel

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
PHP: Exceptions - Teil 2	Zergling-new	Tutorials	5	15.03.2009 11:00
[Erledigt] Exception thrown without a stack frame...	mAy^daY	PHP Tipps 2008	19	04.08.2008 10:44
exceptionhandling - was wird als exception behandelt?	Crypi	PHP Tipps 2008	3	21.06.2008 07:56
Firebug Exception	Blackmail	JavaScript, Ajax und mehr	5	18.06.2008 08:54
PHP/MySQL: QCodo's Code-Generator	Zergling-new	Tutorials	2	09.05.2008 05:33
PHP: Exceptions - Teil 1	Zergling-new	Tutorials	4	05.12.2007 23:31
__autoload und is_subclass_of	Zergling-new	PHP-Fortgeschrittene	1	23.09.2007 18:19
intern: html tag strong im title beim registrieren	brian johnson	Off-Topic Diskussionen	4	13.08.2007 13:03
Ermitteln ob Methode geerbt wurde oder nicht?	MaMo-Net	PHP Tipps 2007	23	14.04.2007 00:28
erbende Exceptions mit PHP 5.1.1 nicht mehr möglich?	HStev	PHP-Fortgeschrittene	4	27.01.2006 14:32
PHP5: Exception im Konstruktor verhindert Instanziierung	Quadaptor	PHP-Fortgeschrittene	4	31.03.2005 17:33
[php5/Exceptions] Exception thrown without a stack frame		PHP-Fortgeschrittene	4	24.11.2004 21:51


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

09.09.2008, 14:54
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	Ich meine das anders: Wenn später wieder jemand throw Exception ('xy') schreibt, sollte das doch trotzdem über einen einheitlichen Handler verarbeitet werden (wenn vielleicht auch eingeschränkt). Deshalb halte ich die Anpassung der handleExceptions für originale Exception für sinnvoller, als allen Code mit neuen Exceptionaufrufen zu versehen. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

10.09.2008, 10:38
David Erfahrener Benutzer Registriert seit: 05.09.2007 Beiträge: 5.044	Das Ding soll doch eh nur unbehandelte Toplevel Exceptions (die hoffentlich eh selten sind) auffangen. Was der Benutzer in so einem Fall braucht, ist die Anzeige "Tut uns furchtbar leid. Der Fehler wurde vermerkt und wird schnellst möglich bearbeitet". Die Detailangaben wandert ins bug tracking. Denn das ist eine unbehandelte toplevel exception: ein bug. Eventuell bekommt der Benutzer noch eine tracking id angezeigt - die aber nichts mehr mit der Exception selbst zu tun hat. Ich würde einer Exception-Klasse keine show(int level)-Methode verpassen. Was käme dann als nächstes? callCellphone() ? toString()/getMessage() sollte voll ausreichen.

10.09.2008, 13:29
Higidi Neuer Benutzer Registriert seit: 19.07.2008 Beiträge: 7	Huhu David, danke ja, ich habe mir mitlerweile gleiches gedacht. ich werde es nun auch so bzw. fast so ähnlich machen und ich glaube dank deinem Post ist mir die eigentlich Funktionalität der set_exception_handle Option von PHP nochmal klar geworden. Aus der Sicht hatte ich das bis jetzt noch gar nicht betrachtet, aber das macht ja auch Sinn. Ich danke euch auf jeden Fall allen, die sich bemüht haben mir zu helfen und ich hoffe ich kann gleiches mal zurückgeben. Wünsche euch allen eine schöne Woche und viel Spaß beim Programmieren! Grüße Daniel