Laravel Exceptions: Why and How to Use? Practical Example.

[@王肖毅-m4t]

It is very useful to throw different exceptions and handle them differently in the project.

[@amilsonm]

Friend, is there any way to add balance to multiple users' wallets at once?

[@jamzykimani]

The video and audio is okay. Just a small comment, I noticed the alert message for insufficient balance was green instead of red/orange.

[@Krishnan172]

Sir how do you come up with all new & different topics so frequently on single thing i.e. Laravel. And too for many years. No doubt you have immersed yourself into this for consistent periods, thus it is helping developers like us even today. But how do you do it?

[@LaravelDaily]

I spend 30-60 minutes every day reading Laravel conversations on Twitter, Laracasts forum, Stackoverflow, KZbin. Also, I get a lot of questions from my audience. That way, my pile of ideas is getting only bigger every day.

[@JJ15ASMR]

Great example, I like using custom exceptions the same way (however, I tend to abstract the message to a more user-friendly one when catching since some exceptions might be more targeted at the developer, e.g. API request fails). The only thing I noticed is that your facecam is a bit smaller than before, but I don't think it really matters.

[@LaravelDaily]

Yeah small cam is fine because the videos are not about me :)

[@wowdesigns7436]

There is a problem .. the resolution is very high .. keep it a little low

[@obikwelukyrian6848]

For me, custom exceptions make more sense in packages, when you structure your application in a modular way where every module is seperate. But for a regular laravel app, I don't see why I need to. Yet

[@hentype]

You'd want to use exception for situations where a logic block can fail in multiple ways and want to just catch them altogether. It's an efficient way to deal with those types of errors. Imagine you're using something like a task with an api call to an external service that might not be available at rare times which is out of your control. You might want to catch that as well then push the task for a later retry queue or even skip the current entry next time instead of risking the occasional fatal error and ruining the process.

[@gazorbpazorbian]

great video! I love it, could you make a more in depth video on exceptions and how to use them in your project? I find it confusing when you can simply send an error message without the use of an exception, for example the response could have been return response()->json(["message" => "this is an error"],500)

[@LaravelDaily]

We have a full course on Handling Errors and Exceptions in Laravel: laraveldaily.com/course/exceptions-errors-laravel

[@gryg666]

What are the benefits of putting the exception message as a constructor parameter and using parent constructor over just replacing protected property $message?

[@AlexGower]

I assume because if you want to manually trigger the exception somewhere else with a custom message.

[@gryg666]

@@AlexGower You can still do that using constructor from the Exception class.

[@LaravelDaily]

Good question. Not sure, to be honest, maybe personal preference.

[@logudotcom]

Loved it...

[@al.e.k]

Hello! By the way, all exceptions in this package extend just Exception. But I suppose it would be better to extend from common package-specific exception, e.g. PayPocketException. And then it would be easier to catch package specific range of exceptions, not one by one. In your example you catch only InsufficientBalanceException, but after it you could catch common PayPocketException to make pay flow more reliable. What do you think about it?

[@LaravelDaily]

Maybe that could be the next step, yes.

[@allforone772]

Insufficiency balance is an expected case and can occur many times... in my opinion, it's not at all an exception, just a general workflow.

[@Krishnan172]

Sir will you be available for direct virtual connect on google meet or so? I promise I won't take much of your time.

[@LaravelDaily]

No sorry I don't do personal consulting anymore, just don't have time

[@binaryfire]

Personally I don't think it's a good idea to use exceptions for things that are a normal part of the app's functionality (like "insufficient balance"). Better to handle that with app logic. IMHO exceptions should be reserved for unexpected errors that occur in the code. I.e. things that the developers should be alerted about.

[@genechristiansomoza4931]

Exceptions are normal part of app's functionality

[@binaryfire]

​@@genechristiansomoza4931 From the Oracle Java docs: "Definition: An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program's instructions. When an error occurs within a method, the method creates an object and hands it off to the runtime system. The object, called an exception object, contains information about the error, including its type and the state of the program when the error occurred. Creating an exception object and handing it to the runtime system is called throwing an exception." You can use exceptions however you like, but the idea behind them is they're thrown when an * error * occurs. Using them as shortcut to display error messages to users isn't a great idea. If you start exposing some exception messages to users, there's a higher chance of accidentally exposing others that contain sensitive information. It's better to just use exceptions for recording and report errors via trackers like Sentry / Bugsnag etc. And handle checking for things like insufficient balances using normal code logic. But that's just my opinion. Each to their own.

[@binaryfire]

@@genechristiansomoza4931 I posted a long reply but it disappeared for some reason. Short answer is no, exceptions are usually thrown in response to errors. Not in response to negative conditions in the normal control flow. That's a universally accepted concept in every programming language. A simple if statement to return the "insufficient funds" message if the balance is below the required amount would be better than treating it as an error.

[@shepard153]

​@@binaryfire I agree. Looks like over engineering to me. Exceptions are used when something unexpected happens, like db transaction fails where it shouldn't. Hence the name - exception.

[@patrickgomes2261]

If you are developing a package I would always prefer the exception option like the package shown in the video, its way cleaner in the code to do whatever you want to do, rather then returning a false or true or a array if data, a string or whatever, that you would need to check within a if or switch statement. And no, exception should not only be thrown when some error occurs, for me everything the client is trying to do should be always a success and if not then its an exception, lets say the user tries to pay for something he should be able to but if the card has been declined from the bank then its an exception and many payment gateways follow this. Edit: I am not anyone should throw exception for everything, rather saying its ok to use exception beyond error syntax and stuff like that, especially if you are creating a package or something like this that will be use for other developers, like an api or so.

[@milan1337]

@LaravelDaily As you requested at the start of this video, the audio in this video is way more "roomy" than normal, perhaps due to your new MacBook or maybe the room. Anyway thank you for your videos!

[@LaravelDaily]

That's because of new office room, indeed. But this has been roomy for a week already, that's not about the macbook :) I'm lowering it a bit with Noise Removal

[@milan1337]

@@LaravelDaily oh sorry I must have missed the other videos in the new office. Good luck!

[@shahsawoodshinwari]

Actually, in my real-time projects, I didn't find exceptions helpful or meaningful, so have left using them

[@rutgerhoutdijk3547]

You don't want code that fails silently, exceptions make everything more readable and easy to debug.. You just need to get used to throwing exceptions in your code instead of returning null/false/etc.. 😅