Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python exceptions considered an anti-pattern

sobolevn.me

Post reply on HN
Print view View original

31–40 of 69 posts

Re: Python exceptions considered an anti-pattern

#32

Post by philipov »

mindslight wrote: post #22

It amazes me how enduring formulaic it is to single out some particular design tradeoff of a language, draw up some examples of expressing something where that tradeoff creates worse code, and then act like it's some mortal flaw in the language. Python chose untyped exceptions, period. How is this surprising, given that its basis is untyped parameters? If you don't like that, use Java with its checked exceptions. Or…

Do you mean unchecked exceptions? Python exceptions are strictly typed, that's core to how they work. An except clause will catch subclasses of the target, so you need to have a custom type for each exception you want to raise in your code.

The mistake I see people make is to use built-in exceptions without subclassing, making it impossible to explicitly catch specific errors. Or the opposite, catching Exception, which will catch everything indiscriminately.

Re: Python exceptions considered an anti-pattern

#33

Post by eemax »

The library described in this blog post looks kind of interesting as an implementation of a Maybe monad in python, but the example case is pretty silly.

It re-implements a 4 line function as a 13 line class, but the logic at the caller doesn't get any simpler:

  try:
     result = get_user_profile(id)
  except:
     # handle any exceptions...
vs. with the library:

  result = FetchUserProfile(id)
  if (result is a Failure):
    # handle the failure
  # do something with the result

Re: Python exceptions considered an anti-pattern

#34

Post by _ZeD_ »

sobolevn wrote: post #3
detaro wrote: post #2

The interesting bit starts at https://sobolevn.me/2019/02/python-exceptions-considered-an-... , where it introduces a library for wrapping errors in return types, even if it got little to do with the headline. IMHO the article would be stronger with a title about what it presents and without the first half.

Thanks, my idea was to state the problem and propose a solution. Hope, that you will find `returns` helpful.

I'm sorry, but from my perspective - a java developer that has moved to scala - this "let's drop checked exceptions for Either[Exception, T]" stuff... stinks.

And for one specific reasons: Exceptions are not important per se, but also for the stacktrace they take with them, and that is given to you when you need to handle it.

I lost too much time in this last month trying to decipher where the hell stuff happened looking at the stacktraces in the logs.

Coming back to the python approach: I like python :) and it's philosophy it's to have unchecked exception, with all what it concerns. The idea is that if you don't know an exception, you really don't know what to do. So let the code blows up - ideally in tests :) - and understand what realistically can happen and how to deal with it.

Re: Python exceptions considered an anti-pattern

#35

Post by jancsika »

mindslight wrote: post #22

It amazes me how enduring formulaic it is to single out some particular design tradeoff of a language, draw up some examples of expressing something where that tradeoff creates worse code, and then act like it's some mortal flaw in the language. Python chose untyped exceptions, period. How is this surprising, given that its basis is untyped parameters? If you don't like that, use Java with its checked exceptions. Or…

The author puts an exception in a didactic example of a "division" function. Then upon finding that the exception cannot easily generalize to all possible use-cases of the didactic example the author concludes:

> So, the sad conclusion is: all problems must be resolved individually depending on a specific usage context.

Why is that sad/revelatory? If the wrapper simply reproduces the behavior of a single infix operator for floating point numbers, then almost by definition one would need to reimplement NaN in order to get a general purpose exception handler.

Re: Python exceptions considered an anti-pattern

#36

Post by posix_compliant »

ltbarcly3 wrote: post #6

"X considered an anti-pattern" article titles considered an anti-pattern

I'm bothered by how frequently people paraphrase this quote Dijkstra to suit their own purposes. Borrowing a famous quote makes me think that they need the help sounding credible.

Re: Python exceptions considered an anti-pattern

#37

Post by sslnx »

Here is the greatest inconvenience of Python exceptions for me. Say you have to try 10 different methods, and you only need one to work. Then you have to write 10 try...except blocks so that each next block is indented relative to previous. This creates unreadable code and does not scale for say 100 methods. The solution that came to mind is labeling try blocks and referring them in except blocks. For example:

  try as method1:
      method1()
  except@method1 try as method2:
      method2()
  except@method2 try as method3:
      method3()
  except@method3:
      raise NoMethodWorked()

Re: Python exceptions considered an anti-pattern

#40

Post by noobiemcfoob »

chillacy wrote: post #8

Counterargument: Exceptions are Pythonic https://jeffknupp.com/blog/2013/02/06/write-cleaner-python-u...

The two articles together present an interesting perspective on python programming philosophy. I'm far more inclined towards the exception approach. And while I like that type annotations exist, using them in examples convinces me that the examples don't apply to all python
Post reply on HN