# Fatal errors - Thread: https://externals.io/message/25277 - Original archive: https://news-web.php.net/php.internals/25277 - Started by Michael Walter on 2006-08-10T10:02:09+00:00 - Messages: 17 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #25277 — Michael Walter — 2006-08-10T10:02:09+00:00 URL: https://externals.io/message/25277#25277 Hi, right now, PHP triggers fatal errors e.g. when accessing private members or calling nonexistant functions. Since this is problematic for obvious reasons, what technical reasons are there for that behavior, and is there a chance that this behaviour will change in a future release? Regards, Michael --- ## #25279 — Lukas Kahwe Smith — 2006-08-10T10:43:01+00:00 URL: https://externals.io/message/25277#25279 · In reply to: #25277 Michael Walter wrote: > Hi, > > right now, PHP triggers fatal errors e.g. when accessing private > members or calling nonexistant functions. Since this is problematic > for obvious reasons, what technical reasons are there for that > behavior, and is there a chance that this behaviour will change in a > future release? what is "problematic" here? Are you simply suggesting to make them E_RECOVERABLE since they do not really leave the engine in a broken state? regards, Lukas --- ## #25280 — Michael Walter — 2006-08-10T10:54:58+00:00 URL: https://externals.io/message/25277#25280 · In reply to: #25279 Yeah. It is problematic that the application has no chance of dealing with the errors itself (consider e.g. php-shell which has to go great lengths to prevent fatal errors from user code leading to php-shell's termination, and still fails at doing this in the general case). Regards, Michael > Michael Walter wrote: > > > […] > > what is "problematic" here? Are you simply suggesting to make them > E_RECOVERABLE since they do not really leave the engine in a broken state? > > regards, > Lukas --- ## #25281 — Pierre — 2006-08-10T11:02:43+00:00 URL: https://externals.io/message/25277#25281 · In reply to: #25280 Hello, > Yeah. It is problematic that the application has no chance of dealing > with the errors itself (consider e.g. php-shell which has to go great > lengths to prevent fatal errors from user code leading to php-shell's > termination, and still fails at doing this in the general case). Why object should act differently than other php variables or constants? Undefined constant, variable, index or offset do not raise a fatal error. It should be the same for the object (constants, props, visibility,...). --Pierre --- ## #25282 — Lukas Kahwe Smith — 2006-08-10T11:04:37+00:00 URL: https://externals.io/message/25277#25282 · In reply to: #25281 Pierre wrote: > Hello, > > > > […] > > Why object should act differently than other php variables or > constants? Undefined constant, variable, index or offset do not raise > a fatal error. It should be the same for the object (constants, props, > visibility,...). Well for privat variables it is kind of different in that someone specifically said "this variable/property exists, but you may only access is from inside and not from the outside". regards, Lukas --- ## #25283 — Michael Walter — 2006-08-10T11:05:33+00:00 URL: https://externals.io/message/25277#25283 · In reply to: #25282 That doesn't justify the error being non-recoverable, though. Regards, Michael > Pierre wrote: > > > […] > > Well for privat variables it is kind of different in that someone > specifically said "this variable/property exists, but you may only > access is from inside and not from the outside". > > regards, > Lukas --- ## #25284 — Derick Rethans — 2006-08-10T11:44:21+00:00 URL: https://externals.io/message/25277#25284 · In reply to: #25281 > > > […] > > Why object should act differently than other php variables or > constants? Undefined constant, variable, index or offset do not raise > a fatal error. It should be the same for the object (constants, props, > visibility,...). He wasn't talking about *undefined variables* at all. The variable *is* defined as private and calling that is ofcourse not allowed. The second thing is that calling normal undefined functions throws a fatal error as well, and it should do that just like calling non existing methods on an object should throw a fatal error. regards, Derick --- ## #25285 — Pierre — 2006-08-10T11:51:05+00:00 URL: https://externals.io/message/25277#25285 · In reply to: #25284 Hello, > > > > […] > > He wasn't talking about *undefined variables* at all. The variable *is* > defined as private and calling that is ofcourse not allowed. I was adding more info to the request. As this problem is not only about this case. For example, try: php -r 'class foo{const bar=2;} echo foo::bar; echo foo::bar2;' In my opinion, echo foo::bar2; should not be a fatal error, just like "echo BAR2;". --Pierre --- ## #25286 — Michael Walter — 2006-08-10T12:11:30+00:00 URL: https://externals.io/message/25277#25286 · In reply to: #25284 Hi, > He wasn't talking about *undefined variables* at all. The variable *is* > defined as private and calling that is ofcourse not allowed. I was talking about all kinds of errors which for no good reason are non-recoverable. Surely, the operation being not allowed is a not a a good error to make the error *non-recoverable*. > The second thing is that calling normal undefined > functions throws a fatal error as well, and it should do that just like > calling non existing methods on an object should throw a fatal error. I'm specifically wondering *why* these errors need be non-recoverable. Ideally, userland would be able to handle them (see the other mails for the rationale). Regards, Michael --- ## #25289 — Ilia Alshanetsky — 2006-08-10T13:29:20+00:00 URL: https://externals.io/message/25277#25289 · In reply to: #25277 > Hi, > > right now, PHP triggers fatal errors e.g. when accessing private > members or calling nonexistant functions. Since this is problematic > for obvious reasons, what technical reasons are there for that > behavior, and is there a chance that this behaviour will change in a > future release? I for one think that the current behavior is the correct one and see no need to change it. Ilia Alshanetsky --- ## #25287 — Michael Walter — 2006-08-10T13:35:08+00:00 URL: https://externals.io/message/25277#25287 · In reply to: #25289 What do you feel is incorrect about allowing mentioned errors to be handled in userspace? Regards, Michael > > > > > […] > > I for one think that the current behavior is the correct one and see > no need to change it. > > Ilia Alshanetsky --- ## #25288 — Ilia Alshanetsky — 2006-08-10T13:39:18+00:00 URL: https://externals.io/message/25277#25288 · In reply to: #25287 > What do you feel is incorrect about allowing mentioned errors to be > handled in userspace? My feeling is that errors such as visibility violations should be addressed during debugging and Q&A phase where simple error logging will be sufficient to track them. Ilia Alshanetsky --- ## #25291 — Unknown W. Brackets — 2006-08-10T14:29:07+00:00 URL: https://externals.io/message/25277#25291 · In reply to: #25288 In the past, many softwares have used an error handler function to provide the following cases: 1. Log the error in a more complicated way than PHP does by default. 2. Send off an email, if necessary, or communicate with another service. 3. Show a generic (e.g. a 500) error message to the client. Now, if I have display_errors set to 0, and my code calls a function that does not exist, or a property it doesn't have access to, the user will see a blank screen (or whatever has been outputted thus far.) Obviously any such egregious errors should have been caught before the, let's say, build got to the beta tester or end client... but by the same logic segfaults should never be found in production C code either. Guess that never happens too, right? In fact, the example on the ref.errorfunc.php doc page shows exactly the sort of thing that is not possible for these types of errors now. Simple error logging seems to fall apart, though, because when your software is on a box you have no control over... and an end user gets an error the end client doesn't even know about, you typically never find out. Even if the end client has opted to send you any errors that happen. -[Unknown] -------- Original Message -------- > > > > > […] > > My feeling is that errors such as visibility violations should be > addressed during debugging and Q&A phase where simple error logging will > be sufficient to track them. > > Ilia Alshanetsky --- ## #25292 — Derick Rethans — 2006-08-10T14:36:59+00:00 URL: https://externals.io/message/25277#25292 · In reply to: #25288 > > > > > […] > > My feeling is that errors such as visibility violations should be addressed > during debugging and Q&A phase where simple error logging will be sufficient > to track them. And I feel this is even more true for calling undefined functions or methods... regards, Derick --- ## #25293 — Pierre — 2006-08-10T14:45:54+00:00 URL: https://externals.io/message/25277#25293 · In reply to: #25292 Hello, > > > > […] > > And I feel this is even more true for calling undefined functions or > methods... Ok, I repeat again what I said, please *read*: It has nothing to do with undefined function or method. Having a fatal error here is insane. --Pierre --- ## #25295 — Marcus Boerger — 2006-08-10T17:32:49+00:00 URL: https://externals.io/message/25277#25295 · In reply to: #25277 Hello Michael, this is the expected behavior. But we migth as well simply remove all those modifiers. That would be much better then providing them in a senseless manner. regards marcus Thursday, August 10, 2006, 12:02:09 PM, you wrote: > Hi, > right now, PHP triggers fatal errors e.g. when accessing private > members or calling nonexistant functions. Since this is problematic > for obvious reasons, what technical reasons are there for that > behavior, and is there a chance that this behaviour will change in a > future release? > Regards, > Michael Best regards, Marcus --- ## #25301 — Michael Walter — 2006-08-10T21:09:47+00:00 URL: https://externals.io/message/25277#25301 What do you mean? Regards, Michael > Hello Michael, > > hwat are you doing there? You turn any new oop feature as oh php 5 into a > joke. What do you aim at? > > Thursday, August 10, 2006, 12:02:09 PM, you wrote: > > > […] > > > […] > > > […] > > > > > Best regards, > Marcus