Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Zend Framework Blog:
Error Handling in Expressive
Mar 24, 2017 @ 09:30:31

The Zend Framework blog has a new tutorial posted by Matthew Weier O'Phinney covering error handling techniques in Expressive with a few examples making use of some custom middleware and logic.

One of the big improvements in Expressive 2 is how error handling is approached. While the error handling documentation covers the feature in detail, more examples are never a bad thing!

In their example they're creating an API resource that returns a list of book details (ones the user has read). The goal is to use the existing error handling for everything except the custom exceptions they want to throw but keep with the JSON handling throughout. First the middleware to handling the API request is shown, complete with sorting and pagination. Then come the custom exception examples for invalid requests and server issues. These exceptions are then put into the Problem Details format with the help of another middleware. This then all tied together with the nested middleware handling Expressive provides and an example of the end result is included.

tagged: error handling expressive custom problemdetails tutorial json middleware

Link: https://framework.zend.com/blog/2017-03-23-expressive-error-handling.html

Eleven Labs Blog:
RabbitMQ: Publish, Consume, and Retry Messages
Feb 03, 2017 @ 12:53:06

On the Eleven Labs blog they're posted a tutorial showing you how to integrate RabbitMQ functionality into your Symfony-based application making use of a few handy tools that do some of the heavy lifting for you and how messages are handled (and what to do when they error).

RabbitMQ is a message broker, allowing to process things asynchronously. There’s already an article written about it, if you’re not familiar with RabbitMQ.

What I’d like to talk to you about is the lifecycle of a message, with error handling. Everything in a few lines of code. Therefore, we’re going to configure a RabbitMQ virtual host, publish a message, consume it and retry publication if any error occurs.

They use the RabbitMQ admin toolkit and Swarrot packages to get the job done. First up is the configuration of the tools, creating a default_vhost.yml file defining a queue and setting up the exchanges and parameters for the default route ("/"). They show an example of what the RabbitMQ UI looks like with this new exchange up and working and how to get more information about this "default" queue. Next up is the consumption and publication of messages. They include an example app/config/config.yml file that defines some settings the Swarrot library (via the SwarrotBundle) needs to understand the connections, consumers and type of provider to use. Finally he shows the configuration so it all knows how to publish messages and a quick example of PHP code that sends a simple string message to be handled by the RabbitMQ workers. The post ends with a bit more configuration and some examples of how to handle errors in this Swarrot/RabbitMQ Admin Toolkit setup and making use of some middleware to help with message retries and number of attempts.

tagged: tutorial rabbitmq symfony bundle swarrot configuration publish consume retry error

Link: http://blog.eleven-labs.com/en/rabbitmq-publish-consume-retry-messages/

Freek Lijten:
Sane defaults over Exceptions
Jan 18, 2017 @ 10:19:13

In a new post to his site Free Litjen talks about defensive programming and the part that sane default handling plays when dealing with exceptions that might pop up.

With over half a million visitors a week and lots of scrapers, bots and other stuff visiting, these exceptions and fatal errors clog up logging quite a bit. Not to the point that we can't handle the volume, but it generates false positives in monitoring channels and it is something we do not want to act upon anyway.

So while I'm happy to see some defensive programming I would be even happier if exceptional situations would be silently resolved to default situations.

The post starts with a quote about defensive programming and how, despite it not being an ideal use, many applications had been seen using exceptions to handle errors and messaging. He proposes another methodology where a set of default values are used instead of just failing on any error hit with the input. The idea has merit but it can also lead to other frustrations like hidden errors in testing and situations where an exception makes more sense than a default.

tagged: sane default value exception error handling defensive programming

Link: http://www.freeklijten.nl/2017/01/04/Sane-defaults-over-Exceptions

Michelangelo van Dam:
Sessions in PHP 7.1 and Redis
Dec 19, 2016 @ 12:09:17

Michelangelo van Dam has a new post to his site looking at using Redis for PHP sessions storage and changes related to the use of PHP 7.1.

In case you have missed it, PHP 7.1.0 has been released recently. Now you can’t wait to upgrade your servers to the latest and greatest PHP version ever. But hold that thought a second…

With PHP 7 lots of things have changed underneath the hood. But these changed features can also put unexpected challenges on your path. [...] One of these challenges that we faced was getting PHP 7.1 to play nice storing sessions in our Redis storage. In order to store sessions in Redis, we needed to install the Redis PHP extension that not only provides PHP functions for Redis, but also installs the PHP session handler for Redis.

When he installed the extension, the latest version (redis-3.1.0), he was given an error message about a failure to read the session data. He shares a bit of code he used to try to debug and diagnose the problem (and a Docker environment) that still resulted in the error. Ultimately they narrowed it down and discovered that it was the Redis extensions causing the problems. Downgrading it from 3.1.0 to 3.0.0 solved the issue right away.

tagged: session redis php71 extension tutorial troubleshoot error connection

Link: http://www.dragonbe.com/2016/12/sessions-in-php-71-and-redis.html

Symfony Blog:
How to solve PHPUnit issues in Symfony 3.2 applications
Dec 14, 2016 @ 11:53:49

On the Symfony blog there's a quick post sharing helpful advice about fixing PHPUnit tests in Symfony 3.2 applications, mostly around an issue involving the use of the "phar" distribution and a class constant error.

If your application uses Symfony 3.2 and you execute PHPUnit via its PHAR file, you'll end up with the following error message [about the "PARSE_CONSTANT" constant]. In Symfony 3.2 applications you can't use the PHAR file of PHPUnit and you must use instead the PHPUnit Bridge.

They provide the commands to get this bridge installed (via Composer) and how to execute the PHPUnit tests post-install (using the "simple-phpunit" command instead). They explain why this process needs to be followed to run the tests correctly and how the PHPUnit-bridge package helps to resolve the situation.

tagged: phpunit issue symfony v32 bridge constant error

Link: http://symfony.com/blog/how-to-solve-phpunit-issues-in-symfony-3-2-applications

Derick Rethans:
Not Finding the Symbols
Dec 01, 2016 @ 09:58:22

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.

tagged: mongodb driver undefined symbol error message extension troubleshoot

Link: https://derickrethans.nl/undefined-symbol.html

Rob Allen:
Handing JSON data errors in Slim 3
Nov 16, 2016 @ 09:12:01

For the Slim framework users out there Rob Allen has a quick new post to his site showing an easy way to handle JSON data errors in a Slim 3 application (besides just a silent failure).

When you send JSON data into a Slim Framework application with a content-type of application/json, then Slim will decode it for you if you use getParsedBody(). [...] If there's an error however, you get [an empty response]. If you care about this, you can use json_last_error_msg() and return an error.

He includes a code example of using this function on an endpoint, providing more information on why the JSON parsing failed. He also includes a "bonus" that makes use of the jsonlint library to inspect the JSON message and provide back a more human-readable message letting the user know what exactly was wrong with the JSON they provided.

tagged: json error slim slimframework jsonlint tutorial jsonlasterrormsg

Link: https://akrabat.com/handing-json-data-errors-in-slim-3/

Handling Laravel Validation Error Messages With Vue.js
Nov 02, 2016 @ 10:32:28

The Scotch.io blog has posted a new tutorial for the Laravel+Vue.js users out there helping you effectively handle validation error messages output through the Vue.js portion of the application.

Recently, I launched a open source side project I was working on called Open Laravel. Open Laravel allows developers to submit open source projects that were built using the Laravel framework. The project submission page uses Vue.js to submit the form asynchronously through an AJAX request. Since I am no longer sending the form the default way (refreshing after form submission), I needed a way to show Laravel form validation error messages. After going back and forth with some forum questions and answers, I was able to make it work.

The tutorial starts you out with a fresh install of Laravel and runs a npm install to get the Laravel Elixir dependencies. They then add in the other dependencies (like Vue.js itself and the use-resource package). Next up are changes on the Laravel side: adding required routes, setting up a "Posts" controller and making a simple view with the form to take in post content. They provide the Javascript for the Vue.js side as well, making use of the vue-resource to connect the form with the POST request to the backend. Finally they tie in the "FormError" component and have it either show failure messages or success messages when everything's good.

tagged: tutorial vuejs laravel form submit vueresoruce error message

Link: https://scotch.io/tutorials/handling-laravel-validation-error-messages-with-vue-js

Master Zend Framework:
Whoops, I Forgot The Error Handler
Sep 21, 2016 @ 12:57:32

The Master Zend Framework site has posted a new tutorial for those out there looking for a bit more from their error handler than just some basic text. In this tutorial Matthew Setter introduces you to the Whoops error handler and how to use it in your Zend Expression application.

Ever experienced HTTP 500’s, but found that your error logs are empty. Ever had no clue why or how this could be happening? Perhaps you forgot to enable the Whoops error handler.

That’s right, perhaps, when you were setting up a Zend Expressive application, you made the mistake which I made recently when you used the Zend Expressive Skeleton Installer. [...] If you chose n, and used a templating engine, then TemplatedErrorHandler, would have been used as PHP's default exception handler.

As a result, no exceptions will be written in your logs. Sure, you’ll see that a 500 error has occurred somewhere in your application. But, the only information you’ll have is [a simple 500 error message].

He notes that the next step for most developers is the log files, trying to find a hint there of what might have broken. If you chose the default logger, nothing will be there as it captures those issues and pushes them to the basic error template (but doesn't output them). He points to where in the configuration you can check to see if you enabled the Whoops error handler and how to test it after you've made the switch. The reason the default is the basic message is that, in production, you don't want information exposed and log messages/code shown to just anyone - that's a big security risk.

tagged: whoops error handler zendexpressive enabled tutorial output

Link: http://www.masterzendframework.com/whoops-errorhandler/

Alejandro Celaya:
Creating a content-based Error Handler for Zend Expressive
Jul 29, 2016 @ 09:26:38

In a post to his site Alejandro Celaya shares a method he worked up for creating a content-based error handler in Zend Expressive - a method of changing the error output based on the content it was passed and the Accept header provided.

In one of my tests of the REST API I saw that when an error occurs (404, 405 or 500), I was getting an HTML response, which is not easy to handle when the client is expecting JSON.

I started to dig on how to fix this problem and thought that using ErrorMiddleware (which is invoked in case of an error) should be the solution, but after some tests I saw that it is only invoked if a regular middleware invokes the next one by passing an error as the third argument or an uncaught exception is thrown. When a route is not matched (404) or it is matched with an incorrect HTTP method (405), the error middleware is not invoked.

After confirming (on Twitter) that this was the intended result he went about looking for another option. He looked into using "Final Handlers" that are called when nothing else matches in the middleware execution chain. They didn't provide one for JSON handling, however, so he had to create his own (code is included in the post) and explains a bit of how it's handling the data and HTTP response code. Unfortunately using this handler made the error output always return JSON so another piece was needed, the content-based detection handler that switches between types based on the Accept header.

tagged: content error handler zendexpressive tutorial json output

Link: http://blog.alejandrocelaya.com/2016/07/29/creating-a-content-based-error-handler-for-zend-expressive/