Handling or Preventing Errors in Python: LBYL vs EAFP - Getting Started & Choosing a Style

[@vsolyomi]

*Shrek donkey picture*: Monads!

[@vsolyomi]

In all seriousness, you're missing one critical thing here: what does you method/function return? In both If you just print, your func will implicitly return None which will propagate to the caller. So you just potentially gave yourself a NoneType exception somewhere up the call stack. And if it explodes far enough you might have no idea where it came from. I think this part is more critical than check vs raise argument. I hope the course gives it some consideration and hopefully at least touches conceptually on generic Result types and errors as values.

[@lemonade2345-j4e]

can you point me to some article that deals with this issue in more elaborate way?

[@vsolyomi]

​@@lemonade2345-j4ealternatively you can go the golang route and always return a tuple of (result, error) but it's about as un-pythonic as you can get. But maybe go read how it works in golang if you're interested, it's absolutely doable in python if you want to go this way

[@vsolyomi]

@@lemonade2345-j4e not much for python specifically sadly, but in other places: rust uses Result types that are then matched on being Ok or Err, their docs are pretty decent. I never found a good Result implementation for python, but there is a Maybe implementation by Eran Kampf out there on github. Maybe is used similar to Result but only checks if something is or is not None. So it's kinda half way there but it's useful in it's own right (ever had to dig deep into nested json checking if every field along the way exist - yeah, no more with this one). If you're looking for better conceptual understanding and more elaborate examples... well, there's Functional Programming in Java by Pierre-Yves Saumont. If you can stomach a java book like that. Maybe there's something better out there, but for python there's like none.

[@vsolyomi]

@@lemonade2345-j4e alternatively you can go the way of golang and always return a tuple of result error and check explicitly, but it's about as unpythonic as it gets I suppose. It's better to ask for forgiveness than permission though, so feel free to try and see. Both approaches - result wrappers and explicit return errors are absolutely doable in python and not even that cumbersome for most use cases, imo.

[@vsolyomi]

@@lemonade2345-j4e one of my comments gets deleted or moderated or something. Anyways ArjanCodes recently made a video on Returns package, it kinda has all you asked for

[@samoylov1973]

LBYL would be better, like this: >>> d = {1: "a"} >>> d.get(2, "there's no such key")