Continuing the discussion from PHP: a fractal of not so bad design:
PHP is built to keep chugging along at all
costs. When faced with either doing something nonsensical or aborting
with an error, it will do something nonsensical. Anything is better
than nothing.
Does anyone see this as an issue? If yes, can you please explain?
Scott
To me, that is a core concept of the Internet itself. Better to have some content showing than nothing at all. Naturally, if âsome contentâ is very little or unusable, that wouldnât be good. But, âget something out thereâ is a good goal. Isnât it?
Scott
I donât think that is an aspect of PHP itself. It is an aspect of how some people write their PHP
Could you expand on that a bit please?
Scott
Well I have never seen a situation where PHP continued on and did something nonsensical when faced with an error situation where the code is written properly.
the most common case I have seen of code continuing on to do something nonsensical is where an exit statement has been omitted from the code.
I think what the author had in mind was that PHP is not strict enough with errors and will continue execution by default. Other languages are more likely to halt execution by themselves while PHP needs to be programmed to do this - like exit codes, etc.
This is a two-edged sword but has advantages. PHP has been designed to be lenient and do the job - so if a programmer makes a mistake or an error happens some time later within the lifetime of a web site then there is still likelihood that most of the stuff will work. Iâve seen many times web pages that spat out PHP notices or warnings but still showed content. If PHP were more âcorrectâ then I would see nothing. And this is the point - if a programmer is inaccessible for some time then I still have the site working instead of being shut down completely. Similar to why browsers donât error out on invalid HTML - uglier but more practical in most cases since HTML is supposed to serve the people who look for information and not the perfectionist programmers who worship correct code.
Today we can have both of the worlds. We can catch all errors in our own way and frameworks are often configured to error out on PHP errors and be strict about them. Plus, PHP 7 is changing things with exceptions replacing errors.
Thanks guys. Good posts!
Scott
In the past I have been grateful to PHP about their updates especially when my web-hosting company upgraded.
Wouldnât the web be a much different place if ONLY valid HTML, CSS, PHP, etc scripts were allowed
If websites error out on invalid HTML there werenât be many websites up and running. 
one reason why XHTML didnât make it eventually.
IE8 is the reason that XHTML hasnât made it yet - all browsers need to support XHTML5 before people can use it.
Not really. Now IE8 is (almost) history and still thereâs no sign of any interest in XHTML among broad audience. My prediction is it will forever remain in trace amounts usage.
Thatâs possible but not everyone agrees. After all it isnât that long since XHTML 5 was released so those working on the standards must believe that it still has a place.
Of course, it has a place but it is a niche place. Iâm almost certain XMTL 5 will not be adopted by the majority of the web, ever. In mass adoption easy stuff wins over well structured stuff - this is part of the reason why PHP got so much adoption as opposed to more structured languages.
As the majority still havenât finished transitioning from HTML 3.2 to HTML 4 ot XHTML 1 it is fairly obvious that the majority donât care about the standards at all and will continue to use whatever works in their browser (regardless of whether it works for their visitors or not).
At least PHP doesnât suffer from the problems that HTML does - The PHP at least has to use code that is valid for the version of PHP being run.
Personally, I donât like PHPâs insouciant attitude towards error handling. It makes programming more difficult because erroneous code is more difficult to catch (since it doesnât immediately blow up).
Sure, error reporting can (and should) be set to the highest level during development to catch errors, but this isnât always known by neophyte programmers who arenât familiar with PHPâs error handling system. They could be accidentally manipulating an array as a string, and they wouldnât even be notified of the non-sensical output if their error reporting settings werenât high enough. This directly goes against what PHP tries to be, and thatâs a beginner friendly and pragmatic language.
Not only that, itâs easy for experienced programmers to fall foul to PHPâs lack of strictness. As an example, Iâve forgotten multiple times that PHPâs CLI doesnât default to E_ALL when reporting errors, which has wasted a lot of my time for little reason.
Itâs actually one of the reasons why Iâm so attracted to Elixir programming. Elixir takes a leaf out of Erlangâs book by failing fast and failing hard. It doesnât allow non-sensical coercions or mis-handling of data without erroring out immediately. This is great for development because problems can be caught quickly. Iâd therefore rather erroring is loud and clear rather than having something output that wasnât quite rightâŚ
The best things life are built to keep going. Namely humans themselves. Just because we run into an error/issue we are programmed to keep going. So I say php is ahead of its time not before.
That is made by design though. It makes no sense to complain about a design, when in fact it is THE design. The proper thing to do is understand the design.
So, the real deal here is, as you mentioned, is for the dev to understand there are different error reporting levels and how PHP reports errors. The very first question a dev should ask before starting to develope is - Is PHP (both PHP-FPM and CLI) configured at the highest level of error reporting possible? And when the application is moved to production, the dev should be certain the settings are changed, so the errors go to logs and not the userâs screen.
Scott
I donât disagree that itâs bad when things are built to keep going, not in any way. Looking at Elixir again, whilst it fails fast and fails hard, applications built in Elixir isolate parts of themselves (such as each application dependency) in separate processes. If a dependency crashes, it will not crash the whole application since it runs in a separate process, and nor will it crash any other dependencies since they also run in separate processes. Even better, Erlangâs OTP manager can handle the automatic restarting of these crashed processes, which creates an incredibly reliable and fault-tolerant system that is built to withstand unexpected crashes.
What I disagree with is how PHP chooses to keep going. Taking the array to string example again, it will simply take an array to be the string âArrayâ when coerced. Iâd much rather PHP crashed loud and clear with an Error exception in this case (and numerous other cases) than to use an obviously useless string form of the array. The error reporting level should not have to matter, it is obviously a non-sensical coercion and the output is useless, so why allow it?
Sure it makes sense to complain about the design, particularly if there are better designs out there.
Iâd like to see PHP crash on non-sensical coercions (like array to string). That way, mistakes can be caught immediately, regardless of the error reporting level (which, as I said above, can be mistakenly at the wrong level).
Iâd also like to see better compiler warnings for unintended behaviour. For example, conditions that always evaluate to either true or false should be warned about. This is quite common given PHPâs strict comparison operators (example). The same goes for unreachable code as well (and numerous other things).
You can put the usage of PHPâs error handling system down to an education problem (including the writing of unintended behavioural code), but at the end of the day, developers make mistakes. And itâs because of this simple reason why Iâd like to see PHP catch more of those mistakes for us, hopefully easing development time.
Whilst there are static code analysers (like Phan) that are attempting to solve this problem for us, they are no where near maturity yet, and so are not overly useful yet. Plus a language-level solution would be better IMO, since introducing those new to programming to static code analysis isnât exactly ideal.
