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

Toptal.com:
Clean Code and The Art of Exception Handling
Apr 13, 2016 @ 09:43:50

While not specific to PHP (the examples are in Ruby, in fact) this new tutorial on the Toptal.com blog has some good information and suggestions around the use of exceptions in your applications.

Exceptions require special treatment, and an unhandled exception may cause unexpected behavior. The results are often spectacular.

Over time, these errors, and countless others [...] contributed to the impression that exceptions are bad. But exceptions are a fundamental element of modern programming; they exist to make our software better. Rather than fearing exceptions, we should embrace them and learn how to benefit from them. In this article, we will discuss how to manage exceptions elegantly, and use them to write clean code that is more maintainable.

They start by talking about why exception handling is a good thing and some common practices to help make them more manageable. They suggest that good exception handling can also help make your code more maintainable, extensible and readable in the long run. He suggests creating your own kind of exception hierarchy (more possible in PHP 7) and using them to get more specific on the type of exception that was thrown. He recommends not "rescuing" exceptions more than needed (in PHP this is try/catch) and that it's okay to defer the handling for the exception being thrown and not deal with it right away.

He also reminds you that not all exceptions need handling in your own code (sometimes it's up to the user) and that following conventions on naming can help end users better understand why there's an error. Finally, he recommends logging exceptions as they're major errors in your application, not just data problems or smaller bugs.

tagged: clean code exception handling bestpractice hierarchy trycatch convention

Link: https://www.toptal.com/qa/clean-code-and-the-art-of-exception-handling

Rob Allen:
Improved error handling in Slim 3.2.0
Feb 26, 2016 @ 10:46:53

In this recent post to his site Rob Allen, a developer with the Slim framework project, covers some of the improvements around error handling in the latest version of the framework, v3.2.0.

We released Slim 3.2.0 yesterday which includes a number of minor bug fixes since 3.1.0 and also a few nice improvements around the way we handle errors.

He talks about the previous error handling (suppressing them in favor of a bland error page) and how v3.2.0 changes this by writing them to the error log by default. He also talks about changes around the addition of a PHP 7 error handler that works with the PHP 7 Error exception types and functions the same way as the default Exception handler.

tagged: slim slim3 slimeframework error handling improvement errorlog exception php7

Link: https://akrabat.com/improved-error-handling-in-slim-3-2-0/

Rob Allen:
PSR-7 file uploads in Slim 3
Feb 05, 2016 @ 11:08:23

In a post to his site Rob Allen explains how to handle file uploads in a PSR-7 structure, specifically illustrating with an example using the Slim (v3) framework.

Handling file uploads in Slim 3 is reasonably easy as it uses the PSR-7 Request object, so let's take a look.

He shows how to create a simple index route in a Slim application and render a view containing just a simple form with an upload field and submit button. When the form submits, he uses the getUploadedFiles method on the Slim Request object to get the file information for the upload. He also shows how to check for errors on the upload using the file data as an object and calling the getError method.

tagged: slim3 file upload tutorial handling error psr7 request

Link: https://akrabat.com/psr-7-file-uploads-in-slim-3/

Rob Allen:
Improved error handling in Slim 3 RC1
Sep 08, 2015 @ 12:23:52

Rob Allen has a quick post to his site talking about some of the improved error handling that's been updated in the latest version of the Slim microframework to help make reporting issues easier in multiple contexts.

From RC1 of Slim 3, we have improved our error handling. We've always had error handling for HTML so that when an exception occurs, you get a nice error page [...] However, if you're writing an API that sends and expects JSON, then it still sends back HTML. [...] At least we set the right Content-Type and status code! However, this isn't really good enough. We should send back JSON if the client has asked for JSON. Until RC1, the only way to do this was to register your own error handler.

With Slim 3 the framework handles things more correctly based on the value of the "Accept" header sent along with the request. This value is checked and, if it references JSON or XML, the error message is translated either giving the default output or reporting back for the "notFound" and "notAllowed" error types.

tagged: slimframework slim3 error handling context html json xml accept header

Link: http://akrabat.com/improved-error-handling-in-slim-3/

Davey Shafik:
Changes to Engine Exceptions in PHP 7.0alpha2+
Jul 06, 2015 @ 09:41:29

Davey Shafik has posted about some changes in engine exceptions in the latest alpha of PHP 7 (alpha2+), mainly a small change to how things are named.

While updating my PHP 7 talk “What to Expect When You’re Expecting: PHP 7″ for the DutchPHP Conference 2 weeks ago I noticed a small but significant change to the new Engine Exceptions feature in the newly release alpha 2. [...] However, for alpha2 this hierarchy changed. Engine Exceptions lost their “Exception” suffix, and became Error and and *Error exceptions, and the abstract BaseException class was changed to a Throwable interface.

He points out that this new naming and structure makes it impossible to make a good hierarchal structure for exceptions. He does favor the new format, though, as it does allow for some structure via interface definitions.

tagged: exception handling php7 alpha2 throwable handling hierarchy

Link: http://daveyshafik.com/archives/69185-changes-to-engine-exceptions-in-php-7-0alpha2.html

Davey Shafik:
Changes to Engine Exceptions in PHP 7.0alpha2+
Jul 06, 2015 @ 09:41:29

Davey Shafik has posted about some changes in engine exceptions in the latest alpha of PHP 7 (alpha2+), mainly a small change to how things are named.

While updating my PHP 7 talk “What to Expect When You’re Expecting: PHP 7″ for the DutchPHP Conference 2 weeks ago I noticed a small but significant change to the new Engine Exceptions feature in the newly release alpha 2. [...] However, for alpha2 this hierarchy changed. Engine Exceptions lost their “Exception” suffix, and became Error and and *Error exceptions, and the abstract BaseException class was changed to a Throwable interface.

He points out that this new naming and structure makes it impossible to make a good hierarchal structure for exceptions. He does favor the new format, though, as it does allow for some structure via interface definitions.

tagged: exception handling php7 alpha2 throwable handling hierarchy

Link: http://daveyshafik.com/archives/69185-changes-to-engine-exceptions-in-php-7-0alpha2.html

SitePoint PHP Blog:
Use Laravel Contracts to Build a Laravel 5 Twig Package
Mar 16, 2015 @ 11:52:13

The SitePoint PHP blog has a new tutorial posted showing you how to integrate Twig into a Laravel application with the help of the recently added "contracts" feature of the framework. Twig is a templating library that aims to be fast, secure and flexible for data output in multiple contexts.

Laravel 5 is finally out, and with all the awesome features it brings. One of the new architectural changes is the new Contracts Package. In this article we are going to understand the reasoning behind this change and try to build a practical use case using the new Contracts.

He starts with a brief look at what Contracts are and what it means to use them in a Laravel application. He then shows how to define the package installation (via Composer) to pull Twig in and register it with the application for future use. He creates a simple service provider to register Twig and return a new "TwigFactory" instance. This instance extends the "FactoryConnect" implementing the "ViewFactory" and, along with a custom "TwigView" object can be used just like you would normally output information via Blade.

tagged: laravel contract twig output template handling provider interface

Link: http://www.sitepoint.com/use-laravel-contracts-build-laravel-5-twig-package/

Mathias Noback:
Some questions about the command bus
Jan 12, 2015 @ 09:46:46

Mathias Noback has continued his series looking at the use of command busses in PHP applications. In this third part of his series, he answers some questions that have been asked by his own readers.

So far we've had three posts in this series about commands, events and their corresponding buses and handlers: a wave of command buses, responsibilities of the command bus, from commands to events. Now I'd like to take the time to answer some of the very interesting questions that by readers.

He answers questions about:

  • The difference between commands and events
  • Disadvantages of using a command bus
  • The command as constructor argument
  • How to return a value from the command bus
  • Could commands handle themselves?

Each question comes with a portion of the question from the original author, an explanation and some code where needed to illustrate his point.

tagged: commandbus question answer reader events disadvantages return handling

Link: http://php-and-symfony.matthiasnoback.nl/2015/01/some-questions-about-the-command-bus/

Matthew Weier O'Phinney:
On HTTP, Middleware, and PSR-7
Jan 09, 2015 @ 11:38:17

Matthew Weier O'Phinney has a new post to his site today with a thought about how to make the Zend Framework (both ZF1 & ZF2) easier for developers to get into and use. He suggests that middleware might be the answer.

As I've surveyed the successes and failures of ZF1 and ZF2, I've started considering how we can address usability: how do we make the framework more approachable? One concept I've been researching a ton lately is middleware. Middleware exists in a mature form in Ruby (via Rack), Python (via WSGI), and Node (via Connect / ExpressJS); just about every language has some exemplar. Even PHP has some examples already, in StackPHP and Slim Framework.

[...] The idea is that objects, hashes, or structs representing the HTTP request and HTTP response are passed to a callable, which does something with them. You compose these in a number of ways to build an application.

He gives some examples of current frameworks and libraries that make use of the middleware idea, showing both object and callable methods. He points out that, while middleware is approachable and makes a developer's life easier, it's not something PHP can internally handle. He covers the things a PHP developer would need to access just to get the complete details about a HTTP request and that what's really needed is good HTTP abstraction handling, something the PHP-FIG group has been working on as a part of PSR-7. He includes some examples of how it might be used and where middleware would fit into the picture.

Too often, I feel as PHP developers we focus on the tools we use, and forget that we're working in an HTTP-centric ecosystem. [...] If PSR-7 is ratified, I think we have a strong foot forward towards building framework-agnostic web-focused components that have real re-use capabilities -- not just re-use within our chosen framework fiefdoms.
tagged: middleware http psr7 abstraction language handling

Link: https://mwop.net/blog/2015-01-08-on-http-middleware-and-psr-7.html

Anthony Ferrara:
What About Garbage?
Dec 03, 2014 @ 13:33:44

In his latest post Anthony Ferrara looks at a recent change in the Composer dependency management tool involving a major speed boost, just from disabling the garbage collection.

If you've been following the news, you'll have noticed that yesterday Composer got a bit of a speed boost. And by "bit of a speed boost", we're talking between 50% and 90% speed increase depending on the complexity of the dependencies. But how did the fix work? And should you make the same sort of change to your projects? For those of you who want the TL/DR answer: the answer is no you shouldn't.

He talks about what the actual (one line) change was that sped things up but goes on to talk about why doing this isn't necessarily a good thing. He covers how PHP handles variables internally, how it relates to "pointers" and the copy-on-write functionality. He includes code snippets and gives an overview of how each would be handled by the interpreter. Unfortunately, the way PHP handles things, deleting a variable only removes variable reference, not the value, but does decrement the reference count for it. When that hits 0, garbage collection kicks in and removes associated values too.

He talks about a few other kinds of garbage collection (the reference count method is just one of them) and circles back around to how this relates to Composer's functionality. He points out the number of objects created during the dependency resolution process and what can happen when the root buffer, populated with all of these objects, gets too full (hint: garbage collection). He finishes the post talking about how, in Composer's case, the garbage collection change yielded the performance impact it did, but doesn't suggest it for every project. He also makes a few suggestions as to things that could be done to improve PHP's garbage collection handling.

tagged: garbage collection handling composer disable detail

Link: http://blog.ircmaxell.com/2014/12/what-about-garbage.html