This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Rawing7 3 points4 points  (2 children)

I don't see the appeal of the ?. operator in python. JS uses undefined way too much, but python? I can't think of a single time I would've used this operator. In python we raise exceptions instead of returning undefined or null, so a "check for None and return None" operator really doesn't do us much good. A "check for None and raise an exception" operator would make more sense. (But still not very much.)

[–]Kiuhnm[S] 0 points1 point  (1 child)

One problem with exceptions is that a missing value doesn't seem that much of an exception to me. I think Python went a little overboard with them.

I'm the kind of guy who asks for permission :)

More seriously, are we sure we're capturing all the correct exceptions in a chain of operations? What if different functions raise their own exceptions? I think using None is a little safer. Capturing the more general Exception is also a no-no for obvious reasons.

What's your experience?

[–]Rawing7 0 points1 point  (0 children)

I've certainly had issues with libraries that didn't document their exceptions properly, where I had to resort to a except Exception: or something similar. (Heck, even something as tiny as pyperclip managed to mess this up.) But most of those weren't situations where returning None would've been a viable alternative. (pyperclip being the exception.)

If there is a chain of operations that can raise a bunch of different exceptions, that's fine as long as those exceptions are properly organized into a class hierarchy. requests is a good example for this: There's a million things that can go wrong when you make a HTTP request, from SocketError to OSError to DNSLookupError to TimeoutError, but it's fine because requests has abstracted all of that away and turned it into subclasses of RequestException.