Fehlerbehandlung nur nach error_reporting

Anmerkungen, Fragen und Hinweise zur Konfiguration dürfen in diesem Forum gepostet werden. // Notes, questions, and hints on the configuration can be posted here.
Thalo
Beiträge: 240
Registriert: 10.08.2009, 16:56:52

Re: Fehlerbehandlung nur nach error_reporting

Beitrag von Thalo » 15.11.2010, 14:57:34

Hi,
Ich sehe hierbei jedoch ernste Probleme bei der Kompatibilität auf das APF zukommen, denn damit ist das Framework schon nur noch auf denjenigen Hosting-Paketen einsetzbar, die die Erweiterung auch installiert und aktiviert haben.
Bitte versteh mich nicht falsch, AFAIK setzt Zend bei all seinen Bibliotheken auf die Multibyte-Bibliothek und nicht auf die native String-Bibliothek von PHP. In meiner Zeit in der ich mit Zend gearbeitet habe sind mir dazu keine Probleme aufgefallen, dass sich Nutzer beschwert hätten.
Dagegen steht die Tatsache, dass die für den Parser relevanten Zeichen (=, ", <, >) sowohl in ISO latin1 als auch UTF-8 an der selben Stelle im Zeichensazu aufgehoben sind und der Parser bisher erfolgreich mit beiden Zeichensätzen zurecht kommt.
Das stimmt natürlich für solche Zeichensätze bei denen die ersten 128 Zeichen deckungsgleich mit Ascii sind. Ich weiß nicht wie es bei anderen Zeichencodierungen aussieht, da ich bisher immer nur mit Windows-1252 arbeite (nicht lachen :) ). Sofern man sich auf solche beschrnänkt, wäre es eine Überlegung zwei Formen von Validatoren, Filtern, Taglibs, .. auszuliefern. So müsste nicht jeder für sich sein eigenes Süppchen kochen. Oder?
Hinsichtlich der Abwärts-Kompatibilität mache ich mir keine Gedanken. Eher schon zur Aufwärts-Kompatibilität und zur Performance.
Weißt du näheres zur Performance? Hier muss eben jeder selbst für sich abwegen ob die Performance wichtiger als die Sicherheit der Application ist. Alternativ besteht ja weiterhin die Möglichkeit des Wechsels :)

Ich bin kein wirklich großer von UTF-8, da ich bisher keinen Vorteil für rein deutsch/englische Seiten sehe. Aber bei der Nutzung von Webservices u.ä ist es schon nervig den Payload jedesmal zu hin und her zu codieren. Das sehe sogar ich ein, so dass ich durchaus für UTF-8 entscheiden würde :)

Ich fände es schön, wenn sich die anderen auch mal zu Wort melden würden. Sonst komme ich so als Egomane rüber :)

APFelsahne
Beiträge: 222
Registriert: 18.03.2010, 13:13:07
Wohnort: Ludwigshafen am Rhein
Kontaktdaten:

Re: Fehlerbehandlung nur nach error_reporting

Beitrag von APFelsahne » 15.11.2010, 15:27:22

hi!

ok, meine meinung, utf-8 find ich gut :mrgreen:
sicherheit sticht für mich immer performance aus, aber auch dass muss jeder selbst für sich entscheiden. performance optimierungen sollte man am ende machen, wenn man weiß wos probleme gibt( => yagni, vllt braucht man ja gar keine optimierung, wer weiß). sicherheit hingegehen ist für mich definitiv das größere qualitätsmerkmal, dass kann ich nicht durch bessere hardware (cpu, etc.) verbessern.

zum thema mit singlebyte/multibyte strings kann ich leider nicht viel sagen, fehlt mir etwas die erfahrung, bisher hat ich ohne multibyte keine probleme.

ansonsten scheint mir das aber eher ein andres thema zu sein, als der thread ursprünglich gedacht war. vllt kann man die diskussion ja auslagern?
Grüße, Florian
BildAPF-Extension wsCatalyst

Megger
Beiträge: 1233
Registriert: 04.11.2008, 10:57:37

Re: Fehlerbehandlung nur nach error_reporting

Beitrag von Megger » 15.11.2010, 15:29:21

Hi

Also ich hatte bisher noch keine Probleme mit dem UTF-8 und ich entwickele eigentlich schon eine Weile mit UTF-8. Ab und zu sehe ich mal ein ä,ö,ü in den Kommentaren, welches nicht richtig angezeigt wird in Eclipse. Aber bei der Anwendung selber ist mir soetwas noch nicht aufgefallen, aber meiner Meinung nach ist es nicht schlecht mit UTF-8 zu arbeiten

Das Error-Verhalten des APF an die Einstellung von error_reporting zu hängen finde ich eine sehr gute Idee. Muss bei mir nämlich auch darauf achten, ob ich nun error_reporting für das Produktivsystem umgestellt habe oder nicht (Nur Teile der Anwendung nutzen das APF, der Rest ist historisch gewachsen von einem anderen Programmierer) Im Produktivsystem schalte ich das error_reporting auf 0, habe aber noch ein Error Handler, der mir die Fehler per Email zuschickt. Allerdings hatte ich es schon, dass das APF trotzdem noch Fehler ausgespuckt hatte, weil ich hier vergessen hatte die Fehlerbehandlung umzustellen.
Tutorial: Browsergame mit dem APF (Die ersten Parts handeln von Installation und Inbetriebnahme des APFs, deswegen sicherlich auch für alle Nicht-Browsergame-Programmierer interessant)

APF-Version
  • Entwicklung: 2.0
  • Produktiv: 1.15

Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: Fehlerbehandlung nur nach error_reporting

Beitrag von jwlighting » 15.11.2010, 17:42:25

Hallo,
ansonsten scheint mir das aber eher ein andres thema zu sein, als der thread ursprünglich gedacht war. vllt kann man die diskussion ja auslagern?
Da wäre ich auch für, sonst ist das hier so ein Kuddelmuddel (neudeutsch: Durcheinander).
Grundsätzlich muss ich betonen, dass ich auch UTF-8 nutze, aber bisher noch nie ernstere Probleme hatte. Das APF (oder) teile in 2 Versionen (mb- und Standart-API) fände ich etwas übertrieben, soweit es nicht doch irgendwo Probleme gibt. Und mit PHP6 ist das Problem dann ja (irgendwann mal...) eh gegessen. ;)
Weißt du näheres zur Performance? Hier muss eben jeder selbst für sich abwegen ob die Performance wichtiger als die Sicherheit der Application ist.
Aus den genannten Gründen: Sicherheit. Sonst müssten wir, konsequent betrachtet, jeden Filter und Co ausbauen, damit unsere Anwendung schneller wird... :mrgreen:
dr.e hat geschrieben:Exakt das meinte ich.
Dann sind wir uns ja jetzt einig. Wenn ich den Klausuren-Haufen hinter mir habe, werde ich die Gallery-API erweitern, und kann dann im Newscontroller auf einfache Weise feststellen, ob das Bild in der galerie liegt, oder nicht. Den trigger_error() stelle ich dann wieder auf Warning um, das landet im Bedarfsfall in den Logs.
Die Anforderungen für das Abfangen von "globalen" und nicht vorhersehbaren Fehlern ist sicher an den Einzelfall geknüpft. Insofern kann das APF nur den Mechanismus und den Standard-Fall anbieten. Wie im vorangegangenen Post beschrieben, werden natürlich nur diejenigen Fehler tatsächlich durch den globalen ErrorHandler gefangen, die nicht zuvor schon im Applikations-Code behandelt werden.
Da hast du Recht. Damit hat sich das erledigt, ich hatte irgendwo einen Gehirnbug drin.
wenn dein Model eine Exception wirft, weil ein über einen URL-Parameter geforderter Datensatz nicht existiert, ...
Argh. Jetzt Zweifel ich gerade wieder an meinem (H)MVC-Verständnis. Ich designe mein Model eigentlich immer so, das es URL-Parameter etc ($_GET, $_POST, ...) nicht selbst bezieht, sondern durch den Controller geliefert bekommt. Dementsprechend würde ich das Problem schon im Controller abfangen, und eine Meldung generieren oder iwie anders behandeln.
EDIT: (Für den Fall, das dein "Datensatz" in der DB steht, und nicht in der URL - vergiss es, alles ok, falsch verstanden ;))
Ich möchte jedoch nochmal betonen, dass der APF-ErrorHandler den PHP-eigenen komplett überschreibt (siehe vorheriger Post) und dadurch keine zwei Stellen entstehen, die konfiguriert werden müssen.
IMHO meint Thalo hier einmal Fehler, die vor der Einführung des APF-Handlers entstehen (-> Config über error_reporting()), und einmal alles danach (-> Config über APF-Registry/-Handler).
Worum es mir ging ist, das es für den Anwender wenig durchsichtig ist, weshalb der PHP-Mechanismus, den er sonst immer erfolgreich anwenden konnte, nicht mehr funktioniert.
Daher mein Bestreben mit: default = error_reporting(); Zusätzlich sollte in der Dokumentation (evtl. auch in der Einstiegsdoku des Demopack) auf diesen Sachverhalt und den Unterschied DefaultErrorHandler <-> ProductionErrorHandler hingewiesen werden, um Stolpersteine beim APF-Einstieg zu sprengen.
Der Logger des APF ist so implementiert, dass er sein eigenes Logfile schreibt.
Das ist mir bekannt, doch auch dort finde ich PHP-Fehler häufig nicht, oder es wird für den entsprechenden Tag gar kein Logfile angelegt... :?

Verzeichnisrechte sind 755, Dateirechte der stückweise vorhandenen Logfiles 644, Apache müsste als Eigentümer laufen.
Das ist bewusst so gehalten, dass klar zwischen den Logfiles von PHP und dem Apachen getrennt wird. [...]
Angenommen, nachvollzogen, zugestimmt.

LG :)

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Thalo
Beiträge: 240
Registriert: 10.08.2009, 16:56:52

Re: Fehlerbehandlung nur nach error_reporting

Beitrag von Thalo » 15.11.2010, 18:34:32

Hi,
ansonsten scheint mir das aber eher ein andres thema zu sein, als der thread ursprünglich gedacht war. vllt kann man die diskussion ja auslagern?
dem stimme ich zu. Sollte wohl getrennt und in ein anderes Forum verschoben werden :)

Mir fällt auf, dass das einzige Argument was dagegen spricht "passt schon" ist. Wenn das euer Qualitätsanspruch an eure Software ist, ist es okay. Für ein Framework finde ich dies den falschen Weg. :?

Ein Beispiel wo ein Fehler auftreten kann, von dem der Entwickler in den meisten Fällen nichts mitbekommt ist unter anderem der TextLengthValidator:

äöü -> nicht wie erwartet 3 sondern 6! Zeichen. Dies muss in vielen Fällen nicht unbedingt ein ein Sicherheitsdefizit sein, aber sauber ist das nicht. Spätestens wenn man sich hier auf Filter verlässt stellt dies ein Problem dar. Muss immer erst das Kind in den Brunnen fallen bevor reagiert wird?

Das erweckt in mir, tut mir leid das zu schreiben, den Eindruck, dass viele UTF-8 nur aus "Coolnes-Faktor" benutzen.
IMHO meint Thalo hier einmal Fehler, die vor der Einführung des APF-Handlers entstehen (-> Config über error_reporting()), und einmal alles danach (-> Config über APF-Registry/-Handler).
Nein, das meinte ich nicht. Werde mich dazu aber noch einmal dediziert in einem weiteren beitrag zu äussern. :)

Megger
Beiträge: 1233
Registriert: 04.11.2008, 10:57:37

Re: Fehlerbehandlung nur nach error_reporting

Beitrag von Megger » 15.11.2010, 19:00:05

äöü -> nicht wie erwartet 3 sondern 6! Zeichen.
Das muss ich mal ausprobieren
Das erweckt in mir, tut mir leid das zu schreiben, den Eindruck, dass viele UTF-8 nur aus "Coolnes-Faktor" benutzen.
Ich benutze UTF-8 um flexibel zu bleiben. Heute gibt es die Seite vielleicht nur in Deutsch und Englisch, aber was ist morgen? Vielleicht will ich noch andere Sprachen hinzufügen und da reicht mir dann "Windows-1252" auf einmal nicht mehr aus, also warum nicht gleich mit UTF-8 beginnen?
Tutorial: Browsergame mit dem APF (Die ersten Parts handeln von Installation und Inbetriebnahme des APFs, deswegen sicherlich auch für alle Nicht-Browsergame-Programmierer interessant)

APF-Version
  • Entwicklung: 2.0
  • Produktiv: 1.15

Thalo
Beiträge: 240
Registriert: 10.08.2009, 16:56:52

Re: Fehlerbehandlung nur nach error_reporting

Beitrag von Thalo » 15.11.2010, 19:20:50

Megger hat geschrieben:
äöü -> nicht wie erwartet 3 sondern 6! Zeichen.
Das muss ich mal ausprobieren
Hab dir mal eine Datei angehangen zur Visalisierung :)
Das erweckt in mir, tut mir leid das zu schreiben, den Eindruck, dass viele UTF-8 nur aus "Coolnes-Faktor" benutzen.
Ich benutze UTF-8 um flexibel zu bleiben. Heute gibt es die Seite vielleicht nur in Deutsch und Englisch, aber was ist morgen? Vielleicht will ich noch andere Sprachen hinzufügen und da reicht mir dann "Windows-1252" auf einmal nicht mehr aus, also warum nicht gleich mit UTF-8 beginnen?
[/quote]

Grundsätzlich finde ich das nicht falsch. Aber mit der Änderung des HTTP-Headers ist es nunmal nicht getan. Zumal: das ist eine Sache von 2 Minuten ist.
Dateianhänge
test3.7z
(158 Bytes) 81-mal heruntergeladen

Megger
Beiträge: 1233
Registriert: 04.11.2008, 10:57:37

Re: Fehlerbehandlung nur nach error_reporting

Beitrag von Megger » 15.11.2010, 19:45:27

Aber mit der Änderung des HTTP-Headers ist es nunmal nicht getan
Stimmt, man sollte schon alles auf UTF8 umstellen
Hab dir mal eine Datei angehangen zur Visalisierung :)
Geahnt, gesehen, verstanden :D
Sollte wohl getrennt und in ein anderes Forum verschoben werden :)
Beiträge komplett abtrennen ist kein Problem, aber Beiträge zerstückeln und abtrennen ist dann schon schwieriger

UTF-8 Diskussion -> de/viewtopic.php?f=5&t=517
Tutorial: Browsergame mit dem APF (Die ersten Parts handeln von Installation und Inbetriebnahme des APFs, deswegen sicherlich auch für alle Nicht-Browsergame-Programmierer interessant)

APF-Version
  • Entwicklung: 2.0
  • Produktiv: 1.15

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast