Skip to main content

Recent tweak made to Laravel error handlers

For anyone configuring their own error handlers in Laravel 4.x, a feature suggestion I made has been implemented to have the handlers placed at the top of the queue rather than bottom.

This default behaviour makes more sense given that as you get further into your app, you'll likely be defining handlers less likely to return a response, or more likely to want to pre-empt other error handlers entirely.

While that's a safe assumption, there's still the mechanism to add a handler to the bottom of the pile with pushError() if you end up needing it still.

Here's a quick reminder of how you can use either of these features:

App::error(function (Exception $exception) { /* Your handler here! */ });
App::pushError(function (Exception $exception) { /* Your handler here! */ });

Comments

Popular posts from this blog

Laravel is Good, Facades Aren't

I've been working on some Laravel 4 based packages lately which inevitably results in me also looking at other packages. I've noticed sometimes that people use facades at times that give me pause. The most troubling being from inside their model classes. A quick google turned up this video which assures people "there's still an instance behind everything, we're fine" .  Everything mentioned in the video is true except that there is a very glaring omission. Scope What usually goes out the door at the start of a long series of mishaps in software design is scope . When the desire to obtain a solution is stronger than the desire to consider the implications of a firm approach, mistakes are sure to follow.  Sacrifices like this are made due to the assumption of a high cost to developing carefully. What really is happening however is a false dilemma , being responded to with a convenience decision . It's very easy to write model code like ...

Building .NET Core Nuget Packages

My last blog post was on building and publishing npm packages, specifically for typescript projects. In my opinion, packages are an important fundamental unit in software development. They sit at the confluence of technical competence and collaboration, and represent something the software community should be proud of. Most of the time, you're going to be creating software packages once you're comfortable with some essential pillars: Coding Project structure Software architecture Building Delivery Community Licensing After I got my npm package up and running, my next task was to do the same thing with my C# libraries. Similar to protoculture, I have made a library called praxis .  This is done by leveraging the services and tooling known in the .NET ecosystem as nuget. In this case, praxis abstracts many of the concepts and functionality I require when producing server projects. It builds on top of ASP.NET Core, so in that sense you can almost think of it as ...

Amazon in Winnipeg?

Late last week, Amazon put word out that they're starting to look for a city to locate a second headquarters .  The fuel this announcement provides has the hype train in Winnipeg going so fast, it's missing stops. I'm curious though.  As you've been digesting this exciting news, who have you spoken or listened to? Was it this guy  and his party's historic theft of public infrastructure (pdf) and incompetence with digital strategy ? Or how about this guy , who maintains that Winnipeg doesn't need a proper rapid transit option ?  You know, the kind that might actually catch the eye of handsome Amazon who now has Winnipeg trying to be the belle of the ball. Transit "system", Peggo glitches are free - thanks  @infidelatheist Runner up articles are  Winnipeg's inability to join the 21st centry on active transport  and the  compounding of the aforementioned digital strategy mistakes . Stop Listening to These Guys They are not technol...