Savoir lire les erreurs php

Bonjour à tous !
Je cherche à comprendre comment interpréter, lire, comprendre, les erreurs php, du style :

Code:

---

1 2	Fatal error: Uncaught TypeError: mysqli_query(): Argument #1 ($mysql) must be of type mysqli, null given in /home/_lib2/inc1/fonctions.php:276 Stack trace: #0 /home/_lib2/inc1/fonctions.php(276): mysqli_query() #1 /home/_lib2/backoffice/inc2/prodAcat2.php(430): ...etc...

---

Déjà, dans quel sens ça va ?
Est-ce que c'est :
Argument #1 ($mysql) must be of type mysqli, null given in /home/_lib2/inc1/fonctions.php:276
qui vient de :
Stack trace: #0 /home/_lib2/inc1/fonctions.php(276)
qui vient de:
mysqli_query() #1 /home/_lib2/backoffice/inc2/prodAcat2.php(430)
....
ou l'inverse ...
mysqli_query() #1 /home/_lib2/backoffice/inc2/prodAcat2.php(430)
qui vient de:
Stack trace: #0 /home/_lib2/inc1/fonctions.php(276)
qui vient de :
Argument #1 ($mysql) must be of type mysqli, null given in /home/_lib2/inc1/fonctions.php:276
......si vous voyez c'que j'veux dire ...?

puis, ces : Argument #1 // Stack trace: #0 // mysqli_query() #1
???
comment ça doit se lire ?
je n'ai pas réussi à trouver sur gogole.com car je ne sais pas trop comment poser la question ... :calim2:

note : je suis très procédural (mais pas procédurier, ne vous inquiétez pas... 8O ) , comme mec, les orienté objet, PDO, class ... c'est pas pour moi :lol::lol:

..et si vous connaissez un tuto qui a un pote....ou un pote qui a un tuto, je suis preneur ! :hola: :hola:

Veuillez agréger, six joints, l'expression de mes sincères condoléances ... oups, salutations ...
Bref, Merci d'avance à tous !! :hola:

(oui, c'est pas marrant de debugger un passage php5.6 à php7.4, pour laisser plein de warnings, notices, etc...et devoir passer, plus tard, en php8.2 ...:aie::aie: )

Bonjour,

En réalité, ces erreurs devraient être présentées avec des retours à la ligne. S'ils sont ensuite passés de façon indirecte au travers d'une chaîne de caractères, il est possible qu'ils soient passés à la trappe.

Code:

---

1 2 3 4 5 6 7 8

$ php test.php PHP Fatal error: Uncaught Error: Call to undefined function d() in /tmp/test.php:20 Stack trace: #0 /home/dom/tmp/sp/sp.php(15): c() #1 /home/dom/tmp/sp/sp.php(10): b() #2 /home/dom/tmp/sp/sp.php(23): a() #3 {main} thrown in /tmp/test.php on line 20

---

Donc, #0 est bien la « dernière en date » (et donc la première à être dépilée), ce qui correspond au premier cas dans ton exemple. Ici, l'erreur se produit dans la fonction « c() », qui elle-même est appelée depuis « b() », elle-même encore appelée depuis « a() ».

Citation:

---

puis, ces : Argument #1 // Stack trace: #0 // mysqli_query() #1
???
comment ça doit se lire ?

---

D'abord, en effet, « argument #1 » signifie ici « le premier argument passé à la fonction », donc ici le premier (et assez souvent le seul) paramètre de ta fonction : f(argument). Le « #1 » ici est complètement indépendant du numéro de rang dans la pile (stack).

La pile, elle, est nécessaire dans tous les langages de programmation (assembleur compris) pour conserver l'adresse de retour vers la fonction appelante, qui va poursuivre son traitement une fois que la fonction appelé aura rendu la main (avec son résultat). Donc, ce n'est pas seulement que l'on « vient de prodAcat2.php(430) » (ce qui reste vrai), mais surtout qu'on y est toujours, même si on est actuellement en train de traiter une sous-routine. Si tu es habitué au procédural, tu dois déjà savoir tout cela…

Concernant l'erreur qui t'occupe présentement, dans :

Code:

---

Argument #1 ($mysql) must be of type mysqli, null given in /home/_lib2/inc1/fonctions.php:276

---

…on lit que la variable nommée « $mysql » devrait être de type « mysqli » (selon la fonction à laquelle tu la passes) mais que dans les faits, elle est de type « null ».

C'est une situation assez courante, et probablement due au fait que l'appel chargé d'établir la connexion à la base a échoué auparavant.

Notons enfin que les API mysql (aujourd'hui obsolète) et mysqli ne sont pas les mêmes, et donc non compatibles entre elles. Il faut utiliser l'une ou l'autre, mais de préférence se tourner vers PDO quand même.

Merci Obsidian, t'es un chef , quelles précisions !! :applo::bravo::hola::ccool::chin:

En effet, c'est beaucoup plus lisible avec les retours à la ligne ... !!
Dans la source html, je peux lire les erreurs clairement...mais c'est pas pratique
C'est pas la faute a firefox, ça fait pareil sur edge et chrome
Probleme apache2, php.ini ? ..... ou .htaccess ...?

Pour le msqly_query , oui, c'était bien un manque à l'appel BDD !
J'en ai environ 12 896.254 à traiter .... passage (notamment , dans le backoffice, qui ne me servait plus vraiment jusqu'à présent...) de mysql à mysqli ....

Et ben, merci encore Obsidian !!

Citation:

---

Envoyé par zugolin

Dans la source html, je peux lire les erreurs clairement...mais c'est pas pratique
C'est pas la faute a firefox, ça fait pareil sur edge et chrome
Probleme apache2, php.ini ? ..... ou .htaccess ...?

---

Euuhhh....ben ...non ... c'est normal, étant donné que ce n'est pas écrit en Html !

Je me répond moi-même ... :lol:

Citation:

---

Envoyé par zugolin

Euuhhh....ben ...non ... c'est normal, étant donné que ce n'est pas écrit en Html !

---

Ça c'est probablement dû à un autre cas de figure : PHP peut-être configuré ou non pour renvoyer les messages d'erreur « directement à l'écran » quand il en produit, c'est-à-dire directement dans le document de sortie envoyé à ton navigateur, ceci pour qu'ils apparaissent aux yeux de l'utilisateur si une erreur se produit.

C'est généralement le cas avec les home page hébergées sur le site de ton fournisseur d'accès, si tu les utilises. C'est la directive display_errors qui pilote ce comportement.

Oui, je commence à comprendre l'erreur ....
C'est vrai que j'ai toujours bossé comme ça:
display_errors à : On .. ou insérer un error_reporting .... mais .. c'est pas cool.. DU TOUT ! ....pour mes autres sites !!
Pour le moment, je vais donc faire un "ini_set('display_errors', -1);" sur ma page
Mais ça ne changera rien à mon affichage...