Tomas Votruba has a post to his site sharing his top seven tips for writing exceptions that "everyone will love" and how they could be considered a more than just a programming tool.

Do you ever had that feeling, that you've seen that exception before and you know what it means and how to solve? What if that would be clear even for those who see it for the first time? It would save yours and their time.

Exceptions are not just error state. Exceptions are the new documentation.

He starts off by describing a situation just about any developer would be familiar with, the "circle" where an exception is thrown when something breaks and there's no additional information so you're back to where you started. Based on his work in the EasyCodingStandard he's come up with seven tips to help prevent this in your applications:

1. Make Exception Names for Humans
2. Use " around" Statements
3. What Exactly is Wrong?
4. What is The Wrong Value?
5. What File Exactly is Broken?
6. What Options do I have?
7. Link what You can't Fit 140 Chars

For each item on the list there's code snippets illustrating the suggestion and a brief description for more context.

On the SitePoint PHP blog editor Bruno Skvorc has posted a tutorial introducing you to Xdebug, the powerful debugging tool for PHP applications.

It’s been 15 years since Xdebug first came out. We think this is the perfect opportunity to re-introduce it to the world, and explain how and why it does what it does. Xdebug is a PHP extension (meaning it needs to be compiled and installed into a PHP installation) which provides the developer with some features for debugging.

It starts off by explaining some of the functionality that Xdebug brings to your debugging practices and the features that can help make it flow a little easier. It talks about how it differs from some of the IDE debugging tools and services like Blackfire.io. Next up is the example putting it to use and what the resulting errors look like. The post then gets into the integration of Vagrant with PhpStorm, using the profiler and how to force the rendering in Laravel output (it normally overrides the exception output with its own formatting).

The Laravel Podcast has posted their latest episode, Laravel Love Affairs (#35), with host Matt Stauffer and guests Taylor Otwell and Jeffrey Way.

In this episode, the crew discusses Laracon 2016, new framework features, preferred messaging applications, and Jack McDade possibly cheating on Taylor with Jeffrey.

You can listen to this new episode either using the in-page audio player or by downloading the mp3 directly. If you enjoy the show, be sure to subscribe to their feed and follow them on Twitter to get more information on episodes as they're released.

On the Coder's Lexicon site, there's a recent post talking about the author's love/hate relationship with PHP traits, a relatively new feature of the language that apps for more "drop-in" functionality similar to mixins in other languages.

When I saw the introduction of PHP traits in 5.4.0 I was eager to learn all about them and how they worked. [...] PHP traits, in my opinion, are handy and very flexible. I guess that is the “love” part of my relationship with them. [...] However, I feel that traits also meddle with a bit of the inheritance rules that have been proven time and time again. Is it possible to love as well as hate something at the same time?

He talks first about "the love" he feels for using traits in his code. He talks about their usefulness for geting around PHP's single inheritance structure and being able to "bolt on" functionality as needed. Then comes "the hate" of them, noting that in the wrong hands, they could lead to very messy and lazy coding practices (including the deadly diamond of death problem).

On DZone.com today there's a new post from Eric Hogue talking about the love-hate relationship he has with PHP (as a developer of five years with it).

I have been programming in PHP for 5 years now. I did not choose this language, I had to learn it to work on the code of the company my bosses bought. Since I started, I heard many rants about how bad PHP is. Some where valid, but a lot of them are just blaming the language for bad code written by bad programmers. I am by no mean an expert in programming languages or PHP, but here is my take on the language I use every day.

His "good" section mentions one of the most popular things about the language - its quality of documentation. He also talks about the interactive shell and the community that surrounds the language. In the "bad" category, though, he points out things like the low barrier for entry ("a blessing and a curse"), the changing order of parameters in function calls and that a constructor of a child class doesn't automatically call the parent's constructor.