macht ini_set('track_errors', 1) das Script langsamer?

[Tom]

Hello,

dass das PHP-Paket nicht so ganz optimal programmiert ist, wird hier ja schon anderswo diskutiert...

Ich möchte nun auch in meinen prozeduralen Scripte-Sammlungen die Fehlerbehandlung verbessern.

Dazu möchte ich $php_errormg benutzten, das aber nur beschrieben wird, wenn track_errors eingeschaltet ist. Macht das track_errors eigentlich noch etwas anderes, als die Fehlermeldung, die sonst auf der Standardausgabe oder im Log erscheint auch in die Variable $php_errormsg zu schreiben?

Insbesondere interessiert es mich, ob es die Scriptausführung merklich verlangsamt.

Hat da jemand Erfahrungswerte?

Als Christian Seiler noch mitgepostet hat, hätte der mir ganz schnell drei/vier relavante Stellen im Quellcode gezeigt. Dann hätte ich mir die Frage selbst beantworten können. Die Tipps fehlen mir irgendwie.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Jörg Reinholz]

Ich möchte nun auch in meinen prozeduralen Scripte-Sammlungen die Fehlerbehandlung verbessern.

Dazu möchte ich $php_errormg benutzten, das aber nur beschrieben wird, wenn track_errors eingeschaltet ist.

Die aber nur jeweiligen im Scope gültig ist ...

Insbesondere interessiert es mich, ob es die Scriptausführung merklich verlangsamt.

Hm. ini_set() wirkt nur im Arbeitspeicher und wird genau genommen beim Kompilieren mit abgearbeitet, der Inhalt der Variable steht nur im Arbeitsspeicher und abertausende Iterationen sehe ich nicht. Definiere "merklich". Davon hängt die Antwort ab. Ist Dein "merklich" auf paranoide Weise definiert wäre die Antwort "Ja, sicherlich."

Jörg Reinholz

[Tom]

Hello,

Ich möchte nun auch in meinen prozeduralen Scripte-Sammlungen die Fehlerbehandlung verbessern.

Dazu möchte ich $php_errormg benutzten, das aber nur beschrieben wird, wenn track_errors eingeschaltet ist.

Die aber nur jeweiligen im Scope gültig ist ...

Ja und viel schlimmer: die kann noch nicht mal populated werden mit 'global'. Dann erscheint sie zwar im übergeordneten Scope, aber leider ohne Inhalt.

Einzige Abhilfe:

  
  
global $MYERRORMSG;  ## damit die Fehlerauswertung nicht ins Leere greift  
  
  
function open()  
{  
    global $MYERRORMSG;  
  
    if (!$fp = @fopen('nofile.txt', 'rb')  
    {  
        $MYERRORMSG = $php_errormsg;  
        return false;  
    }  
}  
  
echo "MyErrorMsg: $MYERRORMSG \r\n";  
  
  

Aber das funktionioniert wenigstens.
Wenn ich dann auch noch die Datenbank fertig habe, die die textuellen Fehlermeldungen wieder in eine hierarchische Ordnung eindeutiger Fehlernummern zurückübersetzt, habe ich schon 'was gewonnen.

Insbesondere interessiert es mich, ob es die Scriptausführung merklich verlangsamt.

Hm. ini_set() wirkt nur im Arbeitspeicher und wird genau genommen beim Kompilieren mit abgearbeitet, der Inhalt der Variable steht nur im Arbeitsspeicher und abertausende Iterationen sehe ich nicht. Definiere "merklich". Davon hängt die Antwort ab. Ist Dein "merklich" auf paranoide Weise definiert wäre die Antwort "Ja, sicherlich."

Nee, 100 Taktzyklen darf das schon gerne kosten. PHP ist ja nicht Assembler. Aber da könnte ich den Unsinn dann auch noch selber beseitigen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Sven Rautenberg]

Moin!

Ja und viel schlimmer: die kann noch nicht mal populated werden mit 'global'. Dann erscheint sie zwar im übergeordneten Scope, aber leider ohne Inhalt.

Einzige Abhilfe:

Was soll das "global" im globalen Scope machen? Superglobal gibts nicht für beliebige Variablen.

global $MYERRORMSG;  ## damit die Fehlerauswertung nicht ins Leere greift

function open()
{
    global $MYERRORMSG;

if (!$fp = @fopen('nofile.txt', 'rb')
    {
        $MYERRORMSG = $php_errormsg;
        return false;
    }
}

echo "MyErrorMsg: $MYERRORMSG \r\n";

  
 - Sven Rautenberg

[Tom]

Hello,

Moin!

Ja und viel schlimmer: die kann noch nicht mal populated werden mit 'global'. Dann erscheint sie zwar im übergeordneten Scope, aber leider ohne Inhalt.

Einzige Abhilfe:

Was soll das "global" im globalen Scope machen? Superglobal gibts nicht für beliebige Variablen.

Ein lesender Zugriff auf die Variable liefert keine Notice mehr, aber ein isset() liefert false, solange noch keine Zuweisung an die Variable stattgefunden hat.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Sven Rautenberg]

Moin!

Hello,

Moin!

Ja und viel schlimmer: die kann noch nicht mal populated werden mit 'global'. Dann erscheint sie zwar im übergeordneten Scope, aber leider ohne Inhalt.

Einzige Abhilfe:

Was soll das "global" im globalen Scope machen? Superglobal gibts nicht für beliebige Variablen.

Ein lesender Zugriff auf die Variable liefert keine Notice mehr, aber ein isset() liefert false, solange noch keine Zuweisung an die Variable stattgefunden hat.

Ok, ich interpoliere mal Info:

Du willst die Variable immer existierend haben, und nicht erst beim Auftreten von Fehlern.

Deswegen nimmst du das in diesem Kontext unsinnige "global $var", weil es als Randeffekt das tut, was du willst: Es "benutzt" den Variablennamen und initialisiert mit NULL.

Ein sachlich korrekteres "$var = null" ist an dieser Stelle vermutlich zu viel verlangt. Beachte außerdem, dass "isset()" sowohl bei nichtexistenten Variablen false liefert, als auch bei Variablen, die NULL enthalten.

- Sven Rautenberg

[ChrisB]

Hi,

Ich möchte nun auch in meinen prozeduralen Scripte-Sammlungen die Fehlerbehandlung verbessern.

Dazu möchte ich $php_errormg benutzten

Und in wie fern soll ausgerechnet das hilfreich sein, um die Fehlerbehandlung zu verbessern?

(Ich glaube mich zu erinnern, dass du schon des öfteren darüber geklagt hast, dass PHP keine vernünftigen Error-Codes ausspuckt – aber diese Misere wird doch nicht dadurch besser, dass du jetzt anfängst, *Text*-Fehlermeldungen selber zu analysieren …?)

MfG ChrisB

[Tom]

Hello,

Und in wie fern soll ausgerechnet das hilfreich sein, um die Fehlerbehandlung zu verbessern?

Die Text-Fehlermeldungen sind, soweit ich das bisher feststellen konnte, eindeutig

Ist eben nur ein bisschen umständlich, das rückwärts zu ergründen. Üblicherweise holt man über die Fehlernummer und den Sprachschlüssel eine Textmeldung aus einer Datei ab. Nun muss ich eben über den Textschlüssel eine Fehlerart abholen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[ChrisB]

Hi,

Die Text-Fehlermeldungen sind, soweit ich das bisher feststellen konnte, eindeutig

Ob sie’s auch bleiben – mit kommenden PHP-Versionen/Updates/Bugfixes …?

Ist eben nur ein bisschen umständlich, das rückwärts zu ergründen. Üblicherweise holt man über die Fehlernummer und den Sprachschlüssel eine Textmeldung aus einer Datei ab. Nun muss ich eben über den Textschlüssel eine Fehlerart abholen.

Willst du das für alle möglichen Arten von Operationen/Funktionen machen? Ich nehme an, fopen war nur ein Beispiel?

Also da würde ich schon eher versuchen, so defensiv wie möglich zu programmieren, und alles was sich vorher prüfen lässt auch vorher zu prüfen. Klar, insb. in Bezug auf das Arbeiten mit Dateien etwas schwierig, von wegen TOCTTOU etc. – aber auch da gibt es sicher noch genug sachen, die sich im voraus prüfen lassen, und wo race conditions eher zu vernachlässigen sind (z.B. so Dinge wie, darf ich im Verzeichnis überhaupt schreiben?).

Und für Sonderfälle, die nur unter ganz speziellen Bedingungen auftreten können – weiß nicht, da so einen Aufwand betreiben (und noch dazu so „schmutzigen“)? Da würde ich dem Nutzer vielleicht doch eher sagen, dass er sich an den Admin wenden soll, der sich das ganze dann im error-log anschaut …

MfG ChrisB

[Sven Rautenberg]

Moin!

Ich möchte nun auch in meinen prozeduralen Scripte-Sammlungen die Fehlerbehandlung verbessern.

Was schwebt dir vor?

- Sven Rautenberg

[tron]

Hi,

dass das PHP-Paket nicht so ganz optimal programmiert ist, wird hier ja schon anderswo diskutiert...

wo denn genau bitte?

danke
tron

[M.]

Mahlzeit,

wo denn genau bitte?

Fass mal in ne Kreissäge und frag dann, welcher Zahn dich als erstes erwischt hat ...

[tron]

Hallo

wo denn genau bitte?

Fass mal in ne Kreissäge und frag dann, welcher Zahn dich als erstes erwischt hat ...

ich wollte eigentlich eher darauf hinaus, ob es hier einen Thread gibt, der _aktuell_ dieses Thema diskutiert. Dass PHP nicht so ganz optimal ist, gut, was ist schon optimal? Mich hätte interessiert, was genau an PHP nicht optimal ist. Ich kenne es kaum.

tron

[M.]

Mahlzeit,

ich wollte eigentlich eher darauf hinaus, ob es hier einen Thread gibt, der _aktuell_ dieses Thema diskutiert. Dass PHP nicht so ganz optimal ist, gut, was ist schon optimal? Mich hätte interessiert, was genau an PHP nicht optimal ist. Ich kenne es kaum.

Ok, das hab ich falsch verstanden ;)

[1UnitedPower]

Meine Herren!

dass das PHP-Paket nicht so ganz optimal programmiert ist, wird hier ja schon anderswo diskutiert...

wo denn genau bitte?

Hier: https://forum.selfhtml.org/?t=217315&m=1492384

[tron]

dass das PHP-Paket nicht so ganz optimal programmiert ist, wird hier ja schon anderswo diskutiert...

wo denn genau bitte?

Hier: https://forum.selfhtml.org/?t=217315&m=1492384

thx

[hotti]

Ich kann es mir einfach nicht verkneifen:

wie einfach das in Perl ist ;)

Schöne Grüße!