On the Laravel News site there's a new post sharing information about an upcoming upgrade for the framework's date handling. In Laravel 5.8, there's plans to update the Carbon library to v2.

Thanks to Carbon maintainer @kylekatarnls you will be able to use Carbon 1.0 or Carbon 2.0 staring in Laravel 5.8. The update includes the ability to use Carbon immutable and even make your application use CarbonImmutable as the default.

[...] According to the laravel/framework pull request you can choose which class you want for dates “such CarbonImmutable, Chronos or simply DateTime.”

For those that want to transition to using some of the features Carbon v2 provides, they've linked to an upgrade guide and some information about how localization will change as a re result of the upgrade.

If you're new to PHP and are still learning the ropes, one thing that could be confusing is how the language handles sessions and the data they contain. In this new tutorial from the TutsPlus.com site, they introduce you to the basics of using sessions and the variables they contain to get you up to speed.

Session handling is a key concept in PHP that enables user information to be persisted across all the pages of a website or app. In this post, you'll learn the basics of session handling in PHP.

We'll start with an explanation of how sessions work and how they are related to cookies. Then we'll look at a few code snippets that demonstrate how to work with sessions. You'll learn how to create and destroy sessions, and how to change session variables.

The post starts with a general overview of what a session is and how the information flows back and forth from the user to the server. To illustrate, they provide an example of a simple login process, complete with flow diagram. The tutorial then shows how to:

• start a new session
• get the session ID
• automatically start a session
• destroying a session

It then covers the use of session variables: setting them, removing them and altering their contents.

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 a new post to his site Junior Grossi covers two main methods for testing event handling in Laravel-based applications: either solitary or sociable.

Testing with Laravel is very easy, but it can be a nightmare when the tests depend on Events and Listeners. In this post I’m gonna show you how you can simplify and improve those tests.

[...] When testing events in Laravel, you can fake() events in a very simple way, like the documentation says. The problem is not with the events, but with the listeners, because usually a listener does a single action, but with more than one listener you start writing repeatable tests.

He starts by looking at some of the background behind the ideas of "solitary" and "sociable" as it relates to events. He then gets into the code, providing some examples of event tests (and how it could evolve into larger, unwieldy tests). He provides some recommendations on refactoring tests to help get around these issues. As a bonus at the end of the post he shows how to create sociable tests, complete with example code.

On the Laravel Daily site they've posted a tutorial showing the Laravel users out there how to create and catch custom exceptions in your application. Exceptions are a useful tool to handle "exceptional situations" where something fails badly enough where the application cannot proceed.

Quite often web-developers don’t care enough about errors. If something goes wrong, you often see default Laravel texts like “Whoops, something went wrong” or, even worse, the exception code, which is not helpful at all to the visitor. So I decided to write a step-by-step article of how to handle errors in elegant way and present proper error information to the visitor.

He uses a "user search" task to help illustrate the methods for creating custom exceptions, catch exceptions and showing the error to the user. Code is included as well as screenshots of the output. With the basics of exception handling out of the way, they move the handling off into a service and take it one step further to create a custom "user not found" exception and its use in the search method.

Matthias Noback has a new post to his site with some suggestions about exception handling and user feedback for both the backend experience and UI side.

Designing domain objects is all about offering meaningful behavior and insights through a carefully designed API. [...] So exceptions in your (object-oriented) domain model are not merely meant to signal an exceptional situation. They can be used to prevent invalid or unsupported usage of an object. By offering well-named methods (with sensible parameters) for changing the object's state, and by being very precise about throwing exceptions when invalid use is imminent, you make your domain objects usable in only one way: the way that makes sense. This is the exact opposite of how your domain objects end up looking if you generate getters and setters for every attribute.

He starts by looking at the use of exceptions to help with validation and a few ways they could be used:

• Exceptions get thrown ad hoc, whenever something threatens the consistency of the domain object.
• They often signal that something is about to happen that can't logically happen, like a state change that isn't allowed or conceptually possible.
• Exception messages may contain more information than you'd like to share with the user.
• Validation errors often require internationalization (i18n).

He explains each option and, where it helps, provides code examples to illustrate. He then moves on to the frontend, talking about changes to the UI when exceptions are thrown and some things on his "wish list" for frontend exception handling.

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.

Sergey Zhuk has posted the third part of his series covering the creation of a Memcached client using ReactPHP has the base and allowing for asynchronous operations. In this latest part of the series (part three) he focuses on emitting events for various actions/results in the client code.

In the previous article, we have faced with a problem: how to deal with a broken connection. Now, when the connection is closed all pending requests are rejected with the ConnectionClosedException. If we want to handle this situation we need to attach onRejected handlers to all promises because we can’t guess in advance which one will be the problem.

This [example] code already looks too complex, but also there is no way to find out if the connection was broken or we have manually close it. So, it becomes clear that we need a completely different approach.

He then shows how to make use of this event library to emit events at certain points in the client's state. He includes code examples showing how to use the emit method to throw the event focusing on handling when there's connection issues.

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.

On the Twilio blog they've posted a new tutorial from author Margaret Staples showing you how to create a Symfony 3 project with user handling along with the Friends of Symfony bundle.

User handling is a fundamental part of a ton of web projects. This post will walk through how to get setup using the Symfony 3 framework and the Friends of Symfony bundle so that your project can allow users to register, login and out, and view and edit their User profile. The steps here will serve as a great starting point for your next web project.

She then walks you through the installation of the Symfony standard edition and how to answer some of the interactive setup questions. Once that's set up she shows how to install the FriendsOfSymfony/FOSUserBundle and what configuration options need to be changed to implement it. She then shows how to update the database schema for the new user handling and how to check to be sure the login, registration and profile pages are working as expected.