Fatal error: Uncaught Error: Call to a member function add()

[Bernd]

Guten Morgen,

ich erhalte ab und an folgende Fehlermeldung

Fatal error: Uncaught Error: Call to a member function add() on boolean in monat.php

Hab mir den Code in der besagten Zeile angeschaut und es wird hier gemeckert

$start->add(new DateInterval('PT'.$trennen[0].'H'.$minuten.'M'));

Hier der gesamte Bereich

$CL = $StundenTag + $Pause;

if ($CL != 0) {
  $trennen = explode('.', $CL);

if ($trennen[1] == "25") {
		$minuten = "15";
} elseif ($trennen[1] == "50") {
	  $minuten = "30";
} elseif ($trennen[1] == "75") {
		$minuten = "45";
}
else {
		$minuten = "00";
}

$start = DateTime::createFromFormat('H:i', $inhalt);
$start->add(new DateInterval('PT'.$trennen[0].'H'.$minuten.'M'));

$vslArbeitsende = $start->format('H:i');
} 

Was stimmt hier nicht bzw. warum wird hier gemeckert? Und vor allem wie kann ich den Fehler beheben?

Wenn ich es richtig einschätze kommt die Meldung nur, wenn für eine besagten Zeitraum keine Daten vorliegen?

[pl]

Eine Klasse wirft eine Exception aber Du fängst diese nicht auf. Finde heraus welche Klasse das ist und wende die Methoden des Exceptionmodell zweckmäßig an, also da wo die Exception fallen kann: try/catch.

MFG

[dedlfix]

Tach!

Eine Klasse wirft eine Exception aber Du fängst diese nicht auf.

Das stimmt nicht. Wenn das der Fall gewesen wäre, wäre das Script bereits an der Stelle abgebrochen worden.

Finde heraus welche Klasse das ist und wende die Methoden des Exceptionmodell zweckmäßig an, also da wo die Exception fallen kann: try/catch.

Das hat mit dem vorliegenden Fall nichts zu tun und würde auch nicht weiterhelfen. Zweckmäßig wäre, den Rückgabewert auszuwerten, bevor man das Script in solche Folgefehler laufen lässt. Oder man prüft vorher die Werte, die zu einem Parameter führen, der ein false zum Ergebnis hat statt des erwarteten Objekts.

dedlfix.

[pl]

Fatal error:

Heißt: Exception!

Uncaught Error:

Heißt: Fehler wurde nicht behandelt (Exception nicht aufgefangen)!

MFG

[dedlfix]

Tach!

Fatal error:

Heißt: Exception!

Uncaught Error:

Heißt: Fehler wurde nicht behandelt (Exception nicht aufgefangen)!

Spielt hier keine Rolle. Der Fehler ist ein Folgefehler. Es kommt darauf an, gar nicht erst in diesen Folgefehler zu rennen.

dedlfix.

[Rolf B]

Hallo pl,

ab PHP 7 geht das Folgende. In PHP 5 ging es noch nicht.

try
{
   $start = FALSE;
   $start->add(3);
}
catch (Error $e) {
    echo "Autsch!";
}

Man muss explizit Error (oder Throwable) in die catch-Klausel schreiben, mit Exception oder ErrorException fängt man das nicht (sowohl Error als auch Exception implementieren Throwable, stehen aber untereinander in keiner Vererbungsbeziehung).

Also ja, du hast recht, es wird was geworfen, aber nein, es ist ein Error und keine Exception.

Natürlich könnte man noch in das Main-Script einen fetten try/catch (Error...) legen, um solche Fatal Errors nicht auf's UI durchschlagen zu lassen und zu loggen. Aber dafür hat PHP meines Wissens noch andere Mittel, und man löst damit das akute Problem nicht.

Rolf

[pl]

Also ja, du hast recht, es wird was geworfen, aber nein, es ist ein Error und keine Exception.

Fatal Error heißt für mich Exception. Und wenn man schon weiß, daß der Konstruktor für DateInterval eine Exception werfen kann, wird man diese Zeile

$start->add(new DateInterval('PT'.$trennen[0].'H'.$minuten.'M'));

sowieso umschreiben und Methodenaufrufe verschiedener Klassen bzw. Instanzen nicht einfach so ineinander schachteln ohne jegliche Prüfungen. Eine Zweckmäßige Fehlerbehandlung fehlt da oben ja völlig!

MFG

PS: Die Fehlerbehandlung beginnt übrigens da:

$start = DateTime::createFromFormat('H:i', $inhalt);

mit einer Prüfung ob die Instanz fehlerfrei erstellt werden konnte!

[Rolf B]

Hallo pl,

Fatal Error heißt für mich Exception

Es ist völlig wurscht, was es für dich heißt. Die Meinung der PHP 7 Runtime zählt. Und die wirft ein Error Objekt, kein Exception Objekt. Möglicherweise hättest du bei Perl recht, dass hilft hier nur nicht.

Man kann beides mit try catch fangen, insofern scheide ich gewissermaßen Korinthen aus, aber PHP macht da leider diesen feinen Unterschied.

Rolf

[pl]

hi @Rolf B

Fatal Error heißt für mich Exception

Es ist völlig wurscht, was es für dich heißt.

Man kann auch sagen: Das Programm ist abgeschmiert. Kommt auf dasselbe raus. Der Grund: Keine Fehlerbehandlung.

Punkt.

[pl]

Siehe da: DateInterval::__construct wirft Exception! MFG

[dedlfix]

Tach!

Siehe da: DateInterval::__construct wirft Exception!

Und? Diesen Constructor hat er nicht verwendet.

dedlfix.

[pl]

Tach!

Siehe da: DateInterval::__construct wirft Exception!

Und? Diesen Constructor hat er nicht verwendet.

Doch, hat er. new DateInterval() ruft den mämlich auf.

.

[dedlfix]

Tach!

Siehe da: DateInterval::__construct wirft Exception!

Und? Diesen Constructor hat er nicht verwendet.

Doch, hat er. new DateInterval() ruft den mämlich auf.

Ok, hat er, mein Fehler. Es ist aber trotzdem nicht so wie du hier denkst, denn die Fehlermeldung bezieht sich nicht auf diesen Konstruktor, sondern dass das add() nicht in $start existiert. Das ist, wie gesagt, ein Folgefehler, für den die bessere Strategie ist, ihn von vorn herein zu vermeiden, anstatt ihn abzufangen.

dedlfix.

[pl]

Ok, hat er, mein Fehler. Es ist aber trotzdem nicht so wie du hier denkst, denn die Fehlermeldung bezieht sich nicht auf diesen Konstruktor, sondern dass das add() nicht in $start existiert.

Doch die Methode existiert ja. add() ist eine Methode in DateTime, existiert also! Sie liefert FALSE weil beim Aufruf ein Fehler aufgetreten ist. Wobei es sich bei diesem Fehler um eine Exception handelt die der Konstruktor von DateInterval geworfen hat.

.

[dedlfix]

Tach!

Ok, hat er, mein Fehler. Es ist aber trotzdem nicht so wie du hier denkst, denn die Fehlermeldung bezieht sich nicht auf diesen Konstruktor, sondern dass das add() nicht in $start existiert.

Doch die Methode existiert ja. add() ist eine Methode in DateTime, existiert also!

Sie existiert an einem DateTime-Objekt. In $start steht aber kein solches, sondern ein boolescher Wert, wie die Fehlermeldung sagt.

Sie liefert FALSE weil beim Aufruf ein Fehler aufgetreten ist. Wobei es sich bei diesem Fehler um eine Exception handelt die der Konstruktor von DateInterval geworfen hat.

Das stimmt nicht. Exceptions werden ja nicht leise geworfen, besonders nicht, wenn man sie nicht abfängt. DateTime::createFromFormat() hat offenbar ein false zurückgegeben. Es kann vielleicht sein, dass später noch von new DateInterval() eine Exception geworfen wird, aber dazu muss erstmal das Problem behoben werden, dass in $start ein false zu stehen kommt.

dedlfix.

[dedlfix]

Tach!

ich erhalte ab und an folgende Fehlermeldung

Fatal error: Uncaught Error: Call to a member function add() on boolean in monat.php

Hab mir den Code in der besagten Zeile angeschaut und es wird hier gemeckert

$start->add(new DateInterval('PT'.$trennen[0].'H'.$minuten.'M'));

In $start befindet sich laut der Fehlermeldung ein boolean und kein Objekt, das eine add-Methode hat. Die eigentliche Frage dazu lautet: Wo kommt das boolean her?

$start = DateTime::createFromFormat('H:i', $inhalt);
$start->add(new DateInterval('PT'.$trennen[0].'H'.$minuten.'M'));

Was stimmt hier nicht bzw. warum wird hier gemeckert?

Das sind die relevanten Stellen, die sich auf $start beziehen. Wenn in der zweiten Zeile das boolean angemeckert wird, muss es in der nächstvorhergehenden Zuweisung dahingekommen sein. Und da wäre die Frage, wann DateTime::createFromFormat() ein boolean zurückgibt. Das Handbuch klärt auf: Returns a new DateTime instance or FALSE on failure. Das ist das übliche PHP-Verhalten, dass Fehler über den Rückgabewert signalisiert werden.

Und vor allem wie kann ich den Fehler beheben?

Offensichtlich übergibst du einen Wert, der von DateTime::createFromFormat() nicht verstanden wird. Der Rest ist Programmlogik, dass du die Fälle abfängst, die zu diesem falschen Parameter führen.

Oder vielleicht passt besser zu deinem Anwendungsfall (was ich nicht beurteilen kann), dass du DateTime::createFromFormat() fehlerhaft aufrufst und stattdessen den Rückgabewert auf false testest, und dann anders fortfährst.

dedlfix.

[Bernd]

Hallo,

ich habe den Fehler scheinbar gefunden, verstehe ihn allerdings nicht.

Ausgangspunkt

$datumStart = "2019-03-01";
$datumEnde  = "2019-03-31";

Abgeänderte Version

$datumStart = "2019-03-01";
$datumEnde  = "2019-03-07";

Schon ist der Fehler weg, warum? Was hat das Start und Ende mit diesem zu tun?

$start = DateTime::createFromFormat('H:i', $uss_inhalt);
$start->add(new DateInterval('PT'.$trennen[0].'H'.$minuten.'M'));

Es ist richtig, ich habe Einträge die in der Zukunft liegen, aber es ging ja die ganze Zeit. Das Problem trat erst auf, als ich die zwei oben genannten Zeilen eingefügt habe um das vsl Ende Pro Tag mir zu ermitteln.

[dedlfix]

Tach!

ich habe den Fehler scheinbar gefunden, verstehe ihn allerdings nicht.

Ich kann dir auch nichts sagen, weil im gezeigten Code zu viele Teile fehlen, um nachvollziehbar zu sein.

Schon ist der Fehler weg, warum? Was hat das Start und Ende mit diesem zu tun?

$start = DateTime::createFromFormat('H:i', $uss_inhalt);
$start->add(new DateInterval('PT'.$trennen[0].'H'.$minuten.'M'));

Das muss aus dem nicht gezeigten Code hervorgehen.

Ich kann nur nochmal wiederholen, die Fehlermeldung im Ausgangsposting ist ein Folgefehler, weil DateTime::createFromFormat() nicht korrekt arbeiten konnte und ein false zurückgegeben hat statt eines DateTime-Objekts. Da wird also irgendwas übergeben, womit diese Methode nicht zurechtkommt. Vielleicht hilft eine Kontrollausgabe des übergebenen Wertes, die Unstimmigkeit zu erkennen.

dedlfix.

[Bernd]

Oh mein Gott, ich habe gerade in die DB geschaut weil mir beim Radfahren eine Idee gekommen ist. Bei manchen Einträgen steht bei der Zeit --- ich weiß nicht gerade schlau.

Jetzt habe ich folgendes geändert

if ( $uss_inhalt != "---") {
		$start = DateTime::createFromFormat('H:i', "00:00");
} else {
		$start = DateTime::createFromFormat('H:i', $uss_inhalt);
}

Und schon funktioniert es wieder. Man, und ich sitze zwei Tage an dem Scheiß 😕 @Rolf B hätte jetzt bestimmt gesagt, lass dir Fehler ausgeben. Aber wo hätte ich angesetzt?

Noch eine Frage, ist es möglich hier

!= "---"

nicht nur auf die --- zu prüfen sondern auf alles wo keine Zahlen drin steht? Falls mir so ein Fehler nochmals unterläuft bzw. noch andere Werte in der DB sind die nicht z.B. 07:00 haben. Ich muss auch mal schauen wie die --- da überhaupt rein kommen 😕

[pl]

@Rolf B hätte jetzt bestimmt gesagt, lass dir Fehler ausgeben.

Deine Fehler werden ja ausgegeben: Fatal error: Uncaught Error: .. Nur machst Du keine Anstalten sie zu behandeln.

ALso ich kenne Zeiten, da wurde einem der hier mit solchen Fehlermeldungen in Verbindung mit keiner Fehlerbehandlung hier aufschlug der Code rechts und links um die Ohren gehauen aber sowas von!

MFG

[Tabellenkalk]

Hallo,

ALso ich kenne Zeiten,

Hachja! Und immer schön Gingko nehmen, damit das so bleibt…

Gruß
Kalk

[dedlfix]

Tach!

@Rolf B hätte jetzt bestimmt gesagt, lass dir Fehler ausgeben.

Deine Fehler werden ja ausgegeben: Fatal error: Uncaught Error: .. Nur machst Du keine Anstalten sie zu behandeln.

Nochmal: Das ist ein Folgefehler. Es kommt nicht darauf an, den abzufangen, sondern gar nicht erst in ihn reinzurennen.

dedlfix.

[pl]

Tach!

Nochmal: Das ist ein Folgefehler.

Irrelevant!

Es kommt nicht darauf an, den abzufangen, sondern gar nicht erst in ihn reinzurennen.

Unsinn. Es kommt darauf an, diesen Fehler zu erkennen was mit einer zweckmäßigen Fehlerbehandlung überhaupt kein Problem ist!

.-.-.

[dedlfix]

Tach!

Es kommt nicht darauf an, den abzufangen, sondern gar nicht erst in ihn reinzurennen.

Unsinn. Es kommt darauf an, diesen Fehler zu erkennen was mit einer zweckmäßigen Fehlerbehandlung überhaupt kein Problem ist!

Falls du es nicht mitbekommen hast, du redest von zwei Fehlern, als ob es einer wäre. Die Meldung kommt vom Folgefehler, in deiner verlinkten Antwort behandelst du aber den eigentlichen Fehler. Genau das was ich seit Anfang an propagiere und das du hier als Unsinn bezeichnet hast.

dedlfix.

[pl]

Eine zweckmäßige Fehlerbehandlung kennt keine Folgefehler sondern behandelt Fehler! Im vorliegenden Fall liegt freilich der Fehler weiter zurück, vielleicht sogar im DB Design: Nämlich da wo man beginnt die Konsistenz seiner Daten sicherzustellen und einen Default festlegt.

Der Default ersetzt einen Wert welcher fehlt! Aber auch ein Default ersetzt nicht die Prüfung während der Datenerhebung. Zumal eine Solche offensichtlich händisch erfolgt (Zeiterfassung).

Und selbst wenn man konsistente Daten sicherstellen kann ist das immernoch kein Grund auf eine spätere Fehlerbehandlung beim Verarbeiten dieser Daten zu verzichten.

MFG

[Tabellenkalk]

Hallo,

Deine letzten beiden Sätze waren absolut überflüssig, daher hab ich sie einfach entfernt, um nicht dein gesamtes posting negativ bewerten zu müssen.

Gruß
Kalk

[Matthias Apsel]

Hallo Tabellenkalk,

Deine letzten beiden Sätze waren absolut überflüssig, daher hab ich sie einfach entfernt, um nicht dein gesamtes posting negativ bewerten zu müssen.

Ja, wie so oft – leider. Ich habe jetzt auch noch die Versionen entfernt.

Bis demnächst
Matthias

[dedlfix]

Tach!

if ( $uss_inhalt != "---") {
		$start = DateTime::createFromFormat('H:i', "00:00");
} else {
		$start = DateTime::createFromFormat('H:i', $uss_inhalt);
}

Und schon funktioniert es wieder. Man, und ich sitze zwei Tage an dem Scheiß 😕 @Rolf B hätte jetzt bestimmt gesagt, lass dir Fehler ausgeben. Aber wo hätte ich angesetzt?

Es gibt möglicherweise keine Fehlermeldung. Mehr als error_reporting auf E_ALL zu stellen und display_errors auf on, kannst du nicht machen. Letzteres ist aber schon der Fall, denn du hast ja die Meldung des fatalen Fehlers zu sehen bekommen.

Aber selbst wenn du noch nie auf einen derartigen Folgefehler gestoßen bist, könntest du mit var_dump() anschauen, was denn in $start drinsteht, bevor es in die Zeile mit dem Fehler geht. Da sollte ein false zu sehen sein. Das Handbuch verrät, dass DateTime::createFromFormat() ein false liefern kann, wenn es nicht erfolgreich ist. Was wären wohl Ursachen, um nicht erfolgreich zu sein? Werte, die es nicht verarbeiten kann. Also schaut man sich mal die Werte an, die man da übergibt. Damit sollte dann zu sehen sein, dass es damit natürlich nicht geht. Und nun geht man rückwärts weiter, bis man die Quelle der fehlerhaften Daten gefunden hat. Das wäre beschwerliches aber systematisches Vorgehen und meist zielführender als lediglich Überlegungen anzustellen.

Noch eine Frage, ist es möglich hier

!= "---"

nicht nur auf die --- zu prüfen sondern auf alles wo keine Zahlen drin steht? Falls mir so ein Fehler nochmals unterläuft bzw. noch andere Werte in der DB sind die nicht z.B. 07:00 haben. Ich muss auch mal schauen wie die --- da überhaupt rein kommen 😕

Du solltest nun langsam wissen, dass DateTime::createFromFormat() ein false zurückgibt, wenn ihm die Eingabe nicht schmeckt. Wenn du auf dieses false prüfst, kannst du alle Werte abfangen, die nicht verwertbar sin.

dedlfix.

[pl]

Tach!

Es gibt möglicherweise keine Fehlermeldung. Mehr als error_reporting auf E_ALL zu stellen und display_errors auf on, kannst du nicht machen.

Doch kann er. Z.B. DateTime::getLastErrors befragen wenn eine Instanz nicht erstellt werden konnte. Das ist das Mindeste! Und daß der Konstruktor der anderen Klasse eine Exeption werfen kann die aufgefangen werden sollte wurde hier auch schonmal gesagt!

MFG

[Rolf B]

Hallo Bernd,

wie schon mehrfach erwähnt, gibt createFormFormat FALSE zurück wenn der Input unverdaulich ist.

$start = DateTime::createFromFormat("H:i", $uss_inhalt);
if ($start === FALSE)
   $start = DateTime::createFromFormat("H:i", "00:00");

Wichtig ist das === statt ==, damit PHP nicht versucht, mit Typen zu jonglieren.

Da du das Umfeld des Codes nicht zeigst, kann ich nur hoffen, dass Du mit dem Wert in $start etwas anfangen kannst. Wenn man nur eine Zeit angibt, wird das Tagesdatum eingesetzt. Ein DateTime ohne Datum gibt es nicht.

Rolf

[dedlfix]

Tach!

Wichtig ist das === statt ==, damit PHP nicht versucht, mit Typen zu jonglieren.

Hier nicht. Bei PHP werden Objekte im booleschen Kontext immer zu true. Es besteht keine Gefahr, dass man ein DateTime-Objekt mit false verwechseln könnte, wenn man nur == als Vergleichoperator nimmt, oder einfach nur if ($start) ... oder if (!$start) ... testet.

dedlfix.

[Bernd]

Hallo,

Da du das Umfeld des Codes nicht zeigst, kann ich nur hoffen, dass Du mit dem Wert in $start etwas anfangen kannst. Wenn man nur eine Zeit angibt, wird das Tagesdatum eingesetzt. Ein DateTime ohne Datum gibt es nicht.

das Problem liegt an diesen Einträgen

Diese entstehen wenn ich z.B. einen Eintrag mache, wo ich keine Uhrzeit benötige, du siehst uss_inhalt ist nicht leer sondern hat ein --- drin und diesen Frage ich dann später hier

$start = DateTime::createFromFormat('H:i', $uss_inhalt);

In den regulären Einträgen sieht es so aus

Du siehst, da ist eine Uhrzeit vorhanden. Die --- kommen nur sehr selten vor, deshalb ist mir der Fehler so noch gar nicht aufgefallen.

Das

$datumStart = "2019-03-01";
$datumEnde  = "2019-03-07";

kann ich auch wieder auf den

$datumStart = "2019-03-01";
$datumEnde  = "2019-03-31";

ändern. Lag ja nicht an $start und $ende.

[pl]

Nun, Dein Code sollte schon zu Deinen Daten passen. Und mit einer ordentlichen Fehlerbahandlung hättest Du sofort gesehen was los ist. Ich hab das mal für Dich gemacht:

date_default_timezone_set("europe/berlin");

if( ! $start = DateTime::createFromFormat("H:i", "--") ){
    print_r( DateTime::getLastErrors() );
}

und das gibt aus

Array
(
    [warning_count] => 0
    [warnings] => Array
        (
        )

    [error_count] => 3
    [errors] => Array
        (
            [0] => A two digit hour could not be found
            [2] => Data missing
        )

)

MFG und keine Ursache, für Dich tat ich es gerne.

[Rolf B]

Hallo Bernd,

ich kann auch nur raten. Wird vielleicht wegen irgendeines Quirks in der Konfiguration "2019-03-07" als 3. Juli 2019 interpretiert, statt 7. März? Dann würde 2019-03-31 der dritte Vigintinovember (sic!^[1]) sein, den gibt's in unserem Kalender nicht.

Rolf

---

1. Dezember (decem, lat. 10) ist der 12. Monat. Der 31. Monat muss also mit dem lateinischen Zahlwort für 29 gebildet werden, sofern nicht irgendwelche Kaiser oder Götter dazwischenfunken: viginti novem). ↩︎

[Self-Nachtwächter]

$CL = $StundenTag + $Pause;

if ($CL != 0) {
  $trennen = explode('.', $CL);

if ($trennen[1] == "25") {
		$minuten = "15";
} elseif ($trennen[1] == "50") {
	  $minuten = "30";
} elseif ($trennen[1] == "75") {
		$minuten = "45";
}
else {
		$minuten = "00";
}

Ich erinnere mich daran, Dir dafür extra eine Funktion geschrieben zu haben...

[Bernd]

Hallo,

jetzt verstehe ich so langsam die Welt nicht mehr. Folgende Daten habe ich

Start:

• 08:30

Pause:

• 0.75

Einträge mit Zeiten

• 3
• 0,5
• 4
• 1

Gesamt

• 9.25

bis dahin stimmt es nicht. Was jetzt kommt, kann natürlich nicht stimmen:

vsl. Arbeitsende:

• 09:15 Uhr

Ich habe wieder folgenden Code

$Gesamt = $StundenTag + $Pause;

if ($Gesamt != 0) {

  $trennen = explode('.', $Gesamt);

  if ($trennen[1] == "25") {
    $minuten = "15";
  } elseif ($trennen[1] == "50") {
    $minuten = "30";
  } elseif ($trennen[1] == "75") {
	  $minuten = "45";
  }
  else {
    $minuten = "00";
  }
}

if ( $uss_inhalt != "---") {
  $start = DateTime::createFromFormat('H:i', "00:00");
} else {
	$start = DateTime::createFromFormat('H:i', $uss_inhalt);
}

$start->add(new DateInterval('PT'.$trennen[0].'H'.$minuten.'M'));

$vslArbeitsende = $start->format('H:i');

Wenn ich mir $trennen[0] und $trennen[1] mit var_dump ausgeben lasse, erhalte ich fogendes

var_dump($trennen[0]);
//string(1) "9" 
echo "<br>";
var_dump($trennen[1]);
//string(2) "25"

Die 9.25 passen also wieder und ich übergebe auch die richtigen Daten? Was läuft in diesem Fall schief? Seht ihr den Fehler?

[dedlfix]

Tach!

Was läuft in diesem Fall schief? Seht ihr den Fehler?

Fehler sieht man nicht nur durch das Anschauen des Codes. Könntest du bitte mal anfangen, die vielfach gegebenen Hinweise zum Vorgehen in deine Debugging-Versuche einfließen zu lassen. Wenn Code sich anders verhält als erwartet und man das Problem nicht durch draufschauen findet, muss man es genauer untersuchen. Kontrollausgaben von in Variablen gehaltenen Werten vor und nach einer Operation sind ein wichtiges Instrument. Ob Abzweigungen richtig genommen werden, kann man ebenfalls kontrollieren, indem man Texte ausgibt, in welchem Zweig man sich befindet.

Nehmen wir mal diesen Ausschnitt:

if ( $uss_inhalt != "---") {
  $start = DateTime::createFromFormat('H:i', "00:00");
} else {
	$start = DateTime::createFromFormat('H:i', $uss_inhalt);
}

Mit Kontrollausgaben kann das beispielsweise so aussehen:

echo '<pre>';
var_dump($uss_inhalt);
if ( $uss_inhalt != "---") {
  echo "\nBedingung: ungleich\n";
  $start = DateTime::createFromFormat('H:i', "00:00");
} else {
  echo "\nBedingung: gleich\n";
	$start = DateTime::createFromFormat('H:i', $uss_inhalt);
}
var_dump($start);

Man muss sich bei den Kontrollausgaben keine besonders große Mühe bei der Form geben, die sind nur zeitweise drin und sollen nur Hinweise liefern. Es reicht, wenn man unterscheiden kann, was wozu gehört. Dafür hilft das <pre> und gegebenenfalls Zeilenumbrüche.

Wenn du dir nun die Ausgaben an dieser Stelle anschaust, könntest du zu dem Schluss kommen, dass sie wohl nicht der Erwartung entsprechen ...

dedlfix.

[Bernd]

Hallo,

Nehmen wir mal diesen Ausschnitt:

if ( $uss_inhalt != "---") {
  $start = DateTime::createFromFormat('H:i', "00:00");
} else {
	$start = DateTime::createFromFormat('H:i', $uss_inhalt);
}

Mit Kontrollausgaben kann das beispielsweise so aussehen:

echo '<pre>';
var_dump($uss_inhalt);
if ( $uss_inhalt != "---") {
  echo "\nBedingung: ungleich\n";
  $start = DateTime::createFromFormat('H:i', "00:00");
} else {
  echo "\nBedingung: gleich\n";
	$start = DateTime::createFromFormat('H:i', $uss_inhalt);
}
var_dump($start);

Wenn ich mir dieses Ausgeben lasse, erhalte ich folgendes

string(5) "08:30"

Bedingung: ungleich
object(DateTime)#14 (3) {
  ["date"]=>
  string(26) "2019-03-08 00:00:00.000000"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(13) "Europe/Berlin"
}

In $uss_inhalt steht also eine korrekte Zahlt nämlich 08:30 und nicht wie erst wieder vermutet ein ---

[dedlfix]

Tach!

In $uss_inhalt steht also eine korrekte Zahlt nämlich 08:30 und nicht wie erst wieder vermutet ein ---

Ja, und welcher Zweig soll bei konkreter Zahl, genauer Uhrzeit, ausgeführt werden, und welcher wird stattdessen ausgeführt? Und liegt das vielleicht daran, dass der Vergleich oder die Reaktion darauf nicht dem entspricht, was erreicht werden soll.

dedlfix.

[Bernd]

Hallo,

jetzt habe ich es auch gesehen. Es muss natürlich so lauten

if ( $uss_inhalt == "----") {
	$start = DateTime::createFromFormat('H:i', "00:00");
} else {
	$start = DateTime::createFromFormat('H:i', $uss_inhalt);
}

[Rolf B]

Hallo Bernd,

nein, muss es nicht.

Zum einen: Du testest auf "----", bislang war aber von "---" die Rede. Eins, zwei, drei, VIER?

Zum anderen: Wenn z.B. "???" drin steht, hast Du wieder FALSE in $start stehen. Diesen Fall musst Du auf jeden Fall noch behandeln, weil Du sonst wieder mit FALSE->add(...) crashst.

Robuster ist dieser Code. Einfach mal versuchen, und wenn es schief geht, den Default setzen.

$start = DateTime::createFromFormat('H:i', $uss_inhalt);
if (!$start)
   $start = DateTime::createFromFormat('H:i', "00:00");

Rolf

[pl]

Die Idee die dahintersteckt ist, daß es keinen Sinn macht mit einem Objekt weiterarbeiten zu wollen was es gar nicht gibt weil es gar nicht erstellt werden konnte.

Logisch oder?

[dedlfix]

Tach!

Die Idee die dahintersteckt ist, daß es keinen Sinn macht mit einem Objekt weiterarbeiten zu wollen was es gar nicht gibt weil es gar nicht erstellt werden konnte.

Logisch oder?

Deswegen hab ich das bereits in meiner ersten Antwort in diesem Thread vorgeschlagen:

Oder vielleicht passt besser zu deinem Anwendungsfall (was ich nicht beurteilen kann), dass du DateTime::createFromFormat() fehlerhaft aufrufst und stattdessen den Rückgabewert auf false testest, und dann anders fortfährst.

dedlfix.

[pl]

Dein Fehler ist die fehlende Fehlerbehandlung! Du prüfst nicht ob Deine Instanzen erstellt werden! MFG