This is a discussion on Python’s forums about adding something akin to a throws keyword in python.

    • Nevoic@lemm.ee
      link
      fedilink
      arrow-up
      8
      ·
      9 months ago

      Yes, but not because the goal of having exceptions in types is bad, rather Java’s type system isn’t advanced enough to support the ideal solution here.

      Scala 3 is working on experimental capture checking capabilities, which allows functions to express certain capabilities (file access, networking, db, etc.), and CanThrow capabilities (e.g exceptions at the type level) are one reification of this.

      The CanThrow docs I linked have a good introduction into why Java checked exceptions are bad, and how Scala’s alternative is far better. Essentially it comes down to a lack of polymorphism in checked exceptions. In practice this means they’re incredibly verbose outside of simple usecases, and with a very easy escape hatch (RuntimeException), you don’t even get the guarantee of knowing a function without checked exceptions doesn’t throw.

      Python will also have this latter issue. Python’s “typing” in general has this issue actually. Types aren’t validated unless you use an external tool, and even then Any is a leaky abstraction that can hide any level of typing errors, unlike in properly typed languages where it’s not leaky. You need it to be leaky in gradually typed environments, or you wouldn’t be able to use a ton of the Python ecosystem, but this vastly reduces the effectiveness of the typing solution.

      I don’t know if Python’s solution here will address the lack of polymorphism that Java’s solution has, I’ll have to look into it more.

  • onlinepersona@programming.devOP
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    1
    ·
    9 months ago

    When I used to write Java and switched to Python, this was one of the things I missed. It was always quite clear which exceptions I had to catch (or not). Just today, I ran into the issue of trying to cover the exceptions a library could throw without using except: or except Exception as e, but finally gave up and gave in to it. The linter wasn’t happy, but fuck it.

    • Fal@yiffit.net
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      9
      ·
      9 months ago

      It was always quite clear which exceptions I had to catch (or not)

      Lol. You’re literally the only one that likes checked exceptions. And, it seems you think that it actually gives you information about what exceptions to catch. It does not. Most things just catch and rethrow as a RuntimException

      • qwertyasdef@programming.dev
        link
        fedilink
        arrow-up
        7
        ·
        9 months ago

        Hey, I like checked exceptions too! I honestly think it’s one of Javas’s best features but it’s hindered by the fact that try-catch is so verbose, libraries aren’t always sensible about what exceptions they throw, and methods aren’t exception-polymorphic for stuff like the Stream API. Which is to say, checked exceptions are a pain but that’s the fault of the rest of the language around them and not the checked exceptions per se.

      • CodeMonkey@programming.dev
        cake
        link
        fedilink
        arrow-up
        6
        ·
        9 months ago

        I also like checked exceptions. I like having a compile time check that I thought through error scenarios.

        Is it perfect? No, but it should be iterated upon, not discarded.

        FYI, catching and rethrowing as an unchecked exception is a pretty bad anti-patern (and a foul code smell).