On his site Brendt has shared some of his thoughts about why he sees the service locator design pattern as an anti-pattern and harmful to your overall application.

As a Laravel developer, I'm confronted daily with the service locator pattern. Every facade call and several helper functions are built upon it.

[...] During a discussion with my colleagues, I found it difficult to put into words what exactly is wrong with grabbing things out of the container - a service locator - so I decided to write my thoughts down, with an example. [...] I want to highlight three problems with this approach, directly caused by the use of a service locator.

He goes through a list of where he sees the use of the service locator functionality causing problems including:

• getting runtime instead of compile-time errors
• obfuscation of actual functionality
• increased cognitive load

He ends the post with a quick suggestion on how to solve the issue: use actual dependency injection instead of "magic" locators.

On the Laravel News site there's a tutorial posted looking ahead at PHP 7.3 and some of the changes coming for JSON error handling.

One of the new features coming to PHP 7.3 is better error handling for json_encode() and json_decode(). The RFC was unanimously accepted by a 23 to 0 vote. Let’s take a look at how we handle JSON errors in <= PHP 7.2, and the new improvements coming in PHP 7.3.

They start with an example of how PHP developers would normally check for JSON parsing errors and the typical response when it fails. In the proposed functionality for PHP 7.3 and optional JSON_THROW_ON_ERROR would be added to throw a JsonException if there was an issue parsing the provided data. This also means that you no longer need to manually request the error message, it would just come through as a part of the standard exception. You can find out the full details on the change in the RFC.

In this new tutorial from the TutsPlus.com site they introduce you to the exception handling that comes along with the Laravel framework and how you can work with it in your own applications.

In this article, we're going to explore one of the most important and least discussed features of the Laravel web framework—exception handling. Laravel comes with a built-in exception handler that allows you to report and render exceptions easily and in a friendly manner.

In the first half of the article, we'll explore the default settings provided by the exception handler. In fact, we'll go through the default Handler class in the first place to understand how Laravel handles exceptions. In the second half of the article, we'll go ahead and see how you could create a custom exception handler that allows you to catch custom exceptions.

You'll need to have a Laravel instance set up already to follow along (instructions not provided here). The tutorial starts with a change to the base configuration for the "APP_DEBUG" and "APP_LOG" settings to enable/disable the error handling and output. Next comes a look at the base exception class for the framework - code included - and a closer look at its report and render methods. Finally it gets into the creation of a custom exception class including the code required to create it and where it should be located in the application for use.

In a new post to his site Rob Allen shows you how to implement CORS in a Zend Expressive application through the use of a simple middleware wrapper that sends the appropriate headers.

On a recent project, I needed to implement CORS support for my Expressive API. The easiest way to do this is to use Mike Tuupola's PSR-7 CORS Middleware.

As this is a standard Slim-Style PSR-7 middleware implementation, we need to wrap it for Expressive, so we make a factory. [...] We then register this in our AppConfigProvider::getDependencies() by adding to the factories key.

He includes the code and configuration changes required to make it all work and includes example output of a request (with headers) from a curl call to the API. He also includes a section on working with JSON error responses and ProblemDetails for when there are issues related to the current CORS policy definition.

Rob Allen has a new post to his site showing how you can customize the Whoops output in a Zend Expressive application. Whoops is a package that provides more well-structured and more attractive error output when an issue comes up.

I find the Whoops error handler page in Expressive quite hard to read and particularly dislike that the error message displayed in the top left is hidden if it's more than a few words long.

To fix this, I discovered that you can provide a custom CSS file to the PrettyPrintHandler and then override to your heart's content! One way to do this is to add a delegator factory to add the additional functionality, so let's do that.

He then includes the configuration changes you'll need to make in the Expressive setup to have it recognize the factory and be able to use it as a dependency. He then includes the code to create the factory itself, adding a path to the local CSS files and pushing the custom whoops.css file into the page handler. Example CSS is included showing an update to the display of the main message, removing the need for a mouseover to view it.

Sergey Zhuk has posted the second part of his series covering the creation of a ReactPHP-based memcached client for asynchronous cache handling. In part one he set up some of the basic structure of the client and got it to a working state. In this latest part he expands on that base and improved the error and connection handling to make it more robust.

In the previous article, we have created a simple streaming Memcached client for ReactPHP ecosystem. It can connect to Memcached server, execute commands and asynchronously return results. In this article we are going to implement some improvements: connection handling [and] errors handling.

He then goes through and makes changes to allow for correct handling of the connection closing where it can either be closed by an option you specify or a forced close from the server. On the error handling side he shows how to handle invalid commands (throwing a WrongCommandException) and a failed command, such as when the value couldn't be stored for one reason or another.

Sebastian De Deyne has a post to his site that shares some hints on how to track down the dreaded "class log does not exist" error in Laravel-based applications.

Every now and then I come across a Class log does not exist exception in Laravel. This particular exception is thrown when something goes wrong really early in the application, before the exception handler is instantiated.

Whenever I come across this issue I'm stumped. Mostly it's related to an invalid configuration issue or an early service provider that throws an exception. I always forget how to debug this, so it's time to document my solution for tracking down the underlying error.

As Laravel hides the real issue behind an error thrown from the logging class, it's difficult to determine where the problem actually lies. The path to solve this and get to the actual error involves a change to the handle method and using the die method to output both the message and stack trace of the issue before Laravel can try to handle it. Obviously this is only really meant for debugging but can be handy when this error is hiding the real reason for the failure.

Rob Allen has a quick post for the Twig and Zend Expressive users out there showing how to display errors if you're not using the Whoops error handler.

If you're not using the Whoops error handler with Expressive and are using the Twig renderer, then you are given no information about the problem that occurred, even in debug mode.

He includes the Twig template to output the error message and, if the application is in "debug" mode, show an optional block of extra information. This provides details about the exception thrown and some of the previous errors. The previous errors are looped about output to provide more context around the failure.

Asmir Mustafic has posted a guide on his site showing how to create custom error codes in the API responses from your Symfony-based application.

When writing APIs, a proper error handling is fundamental. HTTP status codes are a great start, but often when we deal with user inputs is not enough. If out model has complex validation rules, understanding the reason behind an 400 Bad Request error can be not trivial.

Fortunately when for symfony developers there are many libraries to deal with it. Symfony Validator, <a href="https://github.com/symfony/form>Symfony Form, <a href="https://github.com/FriendsOfSymfony/FOSRestBundle>FOS REST Bundle and JMS Serializer combined allows you to have nice error messages to be shown to your users.

He walks you through the code required to create the default error handling with an "author" example. This includes the creation of the entity as well as the form and controller to handle the request/response. He then refactors this away from the default to create the custom error handler with handlers for the message and code to be returned. The post ends with the configuration changes to register it with the application and what the result ends up looking like.

In this new post on thePHP.cc site they talk about calling instance methods statically, more specifically that it should be avoided.

There are quite a few things in PHP 4 that were a bit strange. One example is that PHP 4 allowed static calling of instance methods. [...] To keep backwards compatibility with PHP 4, this code works up to PHP 5, even though [the method in the example[ is not declared static.

[...] Now things will get really weird. When calling an instance method of another class statically, the $this context would carry over from the caller to the called class. In other words, $this suddenly refers to another object instance. While in PHP 5, this used to be an E_STRICT error, PHP 7 will emit an E_DEPRECATED error.

They point out that, while this is definitely odd behavior that shouldn't exist, it hasn't been removed because of PHP's backwards compatibility principles and only removing functionality like this in major versions. So, instead, they recommend calling all non-static methods using an instance of the class injected rather than directly calling them.