In this new post to his site Derick Rethans about an issue that was discovered with the newer version of the PHP MongoDB driver dealing a JSON encoding/decoding error.

Yesterday we released the new version of the MongoDB Driver for PHP, to coincide with the release of MongoDB 3.4. Not long after that, we received an issue through GitHub titled "Undefined Symbol php_json_serializable_ce in Unknown on Line 0".

The driver makes use of the JSON extension's "JsonSerializable" interface to handle some of the BSON types (like binary data). They were surprised that, despite running their tests on a wide range of builds they never came up with this same issue, compiling them from source. The key here is that the JSON extension is bundled along with the binary when compiled this way however some linux distributions do things differently. They ship it as a separate module and, because this could potentially be missing, a JSON error like the one reported could occur. He goes on to talk about some specific examples from various distributions and the simple fix - ensure the JSON extension is loaded before the MongoDB driver is loaded in your installation. This prevents the JSON handling from being missing and the JSON-related error message from popping up.

Constants can be handy when used correctly. Unfortunately, there's some small issues you might want to watch out for. Ben Ramsey discovered one while working with another's code - an undefined constant acting like a string.

From the I-noticed-this-one-day-while-looking-at-a-co-worker's-code department comes a tale about the use of undefined constants in PHP—and relying on this twisted "feature" to make an application function properly.

He relays a little story about the errant code and noticed the constant that wasn't defined and how PHP was treating it like a string. After searching the manual, though, he finds a reference related to the situation showing that it will only throw an E_NOTICE when this happens.

Ben's suggestion is for a bit more than that - at the very least an E_WARNING. Having it down at E_NOTICE won't be seen by most with the default php.ini, and he gives an example as to why it's a bad thing (passing this string/constant into a function and how it handles it).

Constants can be handy when used correctly. Unfortunately, there's some small issues you might want to watch out for. Ben Ramsey discovered one while working with another's code - an undefined constant acting like a string.

From the I-noticed-this-one-day-while-looking-at-a-co-worker's-code department comes a tale about the use of undefined constants in PHP—and relying on this twisted "feature" to make an application function properly.

He relays a little story about the errant code and noticed the constant that wasn't defined and how PHP was treating it like a string. After searching the manual, though, he finds a reference related to the situation showing that it will only throw an E_NOTICE when this happens.

Ben's suggestion is for a bit more than that - at the very least an E_WARNING. Having it down at E_NOTICE won't be seen by most with the default php.ini, and he gives an example as to why it's a bad thing (passing this string/constant into a function and how it handles it).

Spurred on by some comments made in a thread on the php internals mailing list, Wez Furlong has posted this new item on his blog to help clear up some of the confusion around some "undefined behaviour" in the PDO libraries.

Wez goes on to mention that there are some issues with this in the Solaris manual pages as well, as based on others running into this same sort of problem. The realy key here, though, is how the documenttion is defined. Developers, in his opinion, show always treat situations that aren't expressly defined by the manual as a "situation is undefined" rather than making their own expectations.

Spurred on by some comments made in a thread on the php internals mailing list, Wez Furlong has posted this new item on his blog to help clear up some of the confusion around some "undefined behaviour" in the PDO libraries.

Wez goes on to mention that there are some issues with this in the Solaris manual pages as well, as based on others running into this same sort of problem. The realy key here, though, is how the documenttion is defined. Developers, in his opinion, show always treat situations that aren't expressly defined by the manual as a "situation is undefined" rather than making their own expectations.

In this blog post today, ephemera looks at a few of the common PHP errors those new to the language might encounter and an inerpretation of each.

I'd like to dispell the myth that errors are a bad thing. Errors are not a bad thing. Errors are a good thing! They tell you exactly what to fix, and exactly where to fix it. The only mystery is in actually interpretting the language of the error, which is another skill that beginning coders have yet to master. What does the PHP interpreter really mean when it says "unexpected T_VARIABLE"? What's a T_VARIABLE, anyway?

This document is the first in a series that will attempt to help you decode error messages. This version is aimed at very new programmers, working in PHP.

The remainder of the post looks at four of the common errors that might pop up - "unexpected T_VARIABLE", "Maximum execution time exceeded", "Undefined index", and "Syntax error". Under each, she talks about what they mean and how to catch what they're referring to. There's also an example for each to show what the error-causing code might look like.

In this blog post today, ephemera looks at a few of the common PHP errors those new to the language might encounter and an inerpretation of each.

I'd like to dispell the myth that errors are a bad thing. Errors are not a bad thing. Errors are a good thing! They tell you exactly what to fix, and exactly where to fix it. The only mystery is in actually interpretting the language of the error, which is another skill that beginning coders have yet to master. What does the PHP interpreter really mean when it says "unexpected T_VARIABLE"? What's a T_VARIABLE, anyway?

This document is the first in a series that will attempt to help you decode error messages. This version is aimed at very new programmers, working in PHP.

The remainder of the post looks at four of the common errors that might pop up - "unexpected T_VARIABLE", "Maximum execution time exceeded", "Undefined index", and "Syntax error". Under each, she talks about what they mean and how to catch what they're referring to. There's also an example for each to show what the error-causing code might look like.

PHP can throw out some pretty cryptic error messages sometimes, and those new to the langauge might have a difficult time understanding what they relate to. Well, Nexen.net has created a guide to the errors to help you make your way through them (as mentioned in this post).

The errors that PHP throws can sometimes be confusing and mysterious. It outputs them in an effort to make debugging your scripts easier so you can go and correct the error. To help with deciphering them, we have created a guide by looking at the source code for PHP versions: 4.0.0, 4.0.6, 4.1.2, 4.2.3, 4.3.6 and 5.0.0RC2. versions 4.3.6 and 5.0.0RC2.

On the tool they've created, all you need to do is enter in the error code number that the script spits back and it will show you the relevant information. It also has a listing of some of the samples below it to help you narrow it down quickly if you already know what you're looking for.

The site and the tool are all in French.

PHP can throw out some pretty cryptic error messages sometimes, and those new to the langauge might have a difficult time understanding what they relate to. Well, Nexen.net has created a guide to the errors to help you make your way through them (as mentioned in this post).

The errors that PHP throws can sometimes be confusing and mysterious. It outputs them in an effort to make debugging your scripts easier so you can go and correct the error. To help with deciphering them, we have created a guide by looking at the source code for PHP versions: 4.0.0, 4.0.6, 4.1.2, 4.2.3, 4.3.6 and 5.0.0RC2. versions 4.3.6 and 5.0.0RC2.

On the tool they've created, all you need to do is enter in the error code number that the script spits back and it will show you the relevant information. It also has a listing of some of the samples below it to help you narrow it down quickly if you already know what you're looking for.

The site and the tool are all in French.