My FAVORITE Error Handling Technique

In this video, I’ll show you my probably surprising “Let it burn” approach to error handling. Learn why letting your code fail fast can lead to simpler, clearer, and more robust software.

🔖 Chapters:
0:00 Intro
0:09 What is the "Let It Burn" Approach?
1:54 #1 Simplicity and Clarity
4:13 #2 Early Detection
6:09 #3 Serious Errors are not Hidden from You
7:26 #4 Focus on real issues
9:07 Caveats
11:57 Quick Tips for Error Handling
15:04 Final Thoughts

#arjancodes #softwaredesign #python

[eloipereira]

I found that using Pydantic data validation together with a more functional programming style leads naturally and organically to a "let it crash" error-handling pattern. Most of the applications I implement are data-driven and data-intensive, and the majority of the errors happen because data is not well formatted or some unforeseen data behavior. Using Pydantic, I can catch those errors as upstream as possible and avoid spurious computations that might lead to unexpected run-time errors.

[Ziggity]

I've been leading a migration at work of our microservices from Python to Golang. At first I was afraid of the whole errors as values thing but I'm now a believer. It just straight up leads to better error handling. You always have precise control of the flow, no implicit exception ignoring, no nested try except mess. I'm kinda baffled now that try except is the most common error handling paradigm to be honest

[kevinryan]

This highlights why errors-as-values is generally a better error handling paradigm. It can be very difficult to tell when python code (especially from a library) might raise an error.

[nejathakan]

I must say that „4. Focus on real issues“ at 7:28 is the most important point. Especially when you say:“You first deal with those which happen most offen.“

In my opiniin that was the best shot into the bullse eye (term from dart :-))

I enjoyed the rest of your ideas also.

This was the best YouTube post since a long time full of correct and wise best practices instead of garbage what YouTube is full with.

I will consume more of your vids upon now for sure. 👍

Best regards your Nejat

„Gaaaanz liebe Grüße aus Deutschland“

[danielschmider]

one more tip, if you log an error or print it, use repr(error), because that will also include the type of the error

[smibssmibs]

You hit the nail. In my initial Python coding (15 years ago) I was trying to deal with any possible error within any function - even when there was nothing what could be done within given context. My "careful" coding became never ending effort.
With the Let it burn approach the relieve was enormous - similar to when you throw away a backpack full of responsibilities you shall not bear. Suddenly the coding became a fun run.
Thanks for explaining this.

[klmcwhirter]

Fail fast! Python is particularly well suited for this approach that I employ as well.

The real enabler is the "last chance" logger feature.

In reality, robust error handling is an art form where skill only really improves with experience.

Great topic! You covered it well.

[Pierre-SelimHuard]

Fail fast is important with few caveats in mind as you said. I would insist in "Exception are for exceptional behaviour", sometimes handling functionally the issue when it is business related is a better idea. Code has clear typing modeling what can or cannot exist, and conditional are way faster than exception.

[dupdrop]

YES YES

For the life of me I can't understand why people write so many useless try-except blocks in every function that just don't help anything and make the code worse... and often also swallow exceptions they really shouldn't...

I can guess this video idea came from doing consulting work and seeing such code...

[mileta]

I like way how GoLang mages errors. That way you have full control of each error.
BTW liked this video.

[deez_dev]

it's a good approach for some cases imo i think no one can escape errors or predict them and also for more complicated code you would end up with a bunch of ugly "if" statements and we back to zero, but I like the idea of making the obvious errors to not be an error and make the process move on it's brilliant, we don't have to raise errors if we can handle it properly.

[jacmkno]

Nice advice! I follow the same practice when possible. Even still, when errors become visible, you should not start shooting try/catch everywhere, you catch the error, at a point where you can do a proper handling that makes sense at that point of the code, according to the status of the project, to what user's expect, to what you want users to do in that case. Don't make you're code unreadable with insane try/catches specially at points where you don't even even know what to do with the errors.

[fixmymechhangercouk]

It's a good approach and appreciate you sharing when it should not be used!

[cameronball]

excellent video. if someone’s not convinced about fail-fast after watching this, they’re a lost cause.

[gpprudhvi]

I love how amazingly you handle any topic! Thanks for your videos!

[pavfrang]

In the Web API context, a favorable approach is to avoid exceptions in the sense that is best to return a "union" Result type that may contain either the correct value or the error that happened. Exceptions might slow down considerably the calls depending on volume of calls.

[mariusorani]

This is some valuable content, thank you Arjan.

[nathanbrown]

Literally had this case today at work, though kinda the opposite...!
I need to apply a database update for a bunch of items, but one of them was failing. I had left all the error handling to the outermost layer, such that the error was causing the whole database tramsaction to fail.
Easy to therefore find and diagnose, but i realised i really wanted the error handling to allow other items to pass still.
By having the "let it fail" principle, i could therefore choose the point at which i was prepared to handle the exception because i didn't want to fail at that point, but to log and then proceed with the next item.
It makes for much more sensible error handling at the point where the error could be properly processed, not constantly logging it until someone knows what to do with it.

Other parts of legacy code does do that 'print and raise' handling, and it becomes hard to actually work out what errors I'm actually trying to handle and to get the severity/regularity of them

[SkaChild]

Great to hear a bit of sense on the matter. Similar to seeing junior engineers using dict.get, i ask why and they say 'incase the key isnt there'. Great so now we just get a type error 2 lines down when you try and add an int to None

[hodgeyhodge]

My colleagues' favourite technique is to catch-log-throw at every level all the way up. When there's eleven logs, you won't miss it!