Is PHP opaque?

Continuing the discussion from PHP: a fractal of not so bad design:

Ok. Today we’ll get into PHP’s opaqueness.

Eevee asserts:

PHP is opaque: no stack traces by default or for fatals, complex error reporting

I know PHP7 will do better with stack traces and also handle fatal errors better too. How about the rest? Is PHP’s error reporting “complex”? Is PHP opaque at all?

Scott

Hmm…no opinions on this. Ok. I say, PHP is not opaque. If it were, it wouldn’t be so much fun to work with and more importantly, nothing would get done and that can’t be anything further from the truth. A ton of ideas get accomplished with PHP. Even a Gameboy emulator. LOL!

Then again, can PHP be more concise? I think we can agree that yes. It could be. Still, it is more than concise enough. And that is also what matters.

Scott

2 Likes

I would not say its opaque, sure if you just have a PHP installation, the error reporting is not good. Though there is so many good tools that provide very good stack traces (both open source and paid) that it does not matter.

On a side note, aint we all clearly biased towards PHP? So are we able to look through our own curtain to see the bad things with the language?

Can you expand on that a bit please?

As for the tools on stack traces, could you name your favorite please? :smile:

I would imagine every PHP developer has more than once come across some sort of hindrance or annoyance in PHP. If it is bad enough to complain about, it will be and who knows them better than the PHP community members themselves? The question is, are they really “bad enough” to complain about and for the most part, I would say, they aren’t.

Would you agree?

Scott

What I mean is that out of the box, there is no easy way to do proper stack traces with PHP (perhaps the better way of saying is, that there is no easy way to digest/view the information?). If an exception is thrown, you have access to some information if you chose to use it.

My favorite at the moment is Zend Server, you can do a stack trace on a specific page, or just browse the web application/API and afterwards review the requests that had issues, and have all information available including the information the user sent to the server. With the addition of Z-Ray you also have easy access to database stack trace, and breakdown of what happens else in the script. Quite useful when working on API services.

This is actually one of the better perks of the Zend Certified Engineer certification, that you get a license to the developer version (you also get a license to their IDE, but I would not switch to it from PHPStorm).

Today you normally work on WM (vagrant, docker) similar to the clients enviroment, but if I run into a specific issue, I have found that if I spend more than five minutes on tracking it, I switch to a VM with Zend Server and it serves me the information on a platter.

Note. We have not run Zend Server in production, so not sure how it behave under load. There we normally run Ngnix, so to log production data we use New Relic. The track stack they provide on errors is not that detailed (unless the page is logged a transaction), but having the ability to view error logs as they happen in real time is very nice. In the event an issue occur you can drill down by server, cluster etc. and get more detailed information, and by this way see if it is a local issue to a specific server or cluster wide. + setting it up so it automatically sends out alerts if something happens according to the thresholds you set makes you sleep better.

1 Like

Yes, been working with PHP professionally now for 13 years and there is a few things that you learn to just live with and apply workarounds, luckily I feel that we need to use fewer of those now, than a decade ago. IMO PHP is maturing pretty good.

One specific thing that still bothers me is the fmod() since it is unreliable when you work with floats, even if the manual says it is for that (floating point issues). Had some conversations about this four or five years ago, and got told this was a feature :wink:

The problem is that the function is based on IEEE754 floating point numbers, so the “incorrect” result you get in some cases is correct according to how accurate IEEE754 handle floating point. So it is a technical issue with the implementation, but I feel at least a notice could be put in the documentation regarding this potential problem it has.

1 Like

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.