A proposal for java's "throws" in python: Extend type hints to cover exceptions (discuss.python.org)
from onlinepersona@programming.dev to python@programming.dev on 15 Nov 2023 22:33
https://programming.dev/post/5934266

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

#python

threaded - newest

[deleted] on 15 Nov 2023 22:33 next collapse
.
onlinepersona@programming.dev on 15 Nov 2023 22:35 next collapse

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.

patentrechercheur@mastodon.social on 15 Nov 2023 23:10 next collapse

@onlinepersona You just need pip install fuckit

https://pypi.org/project/fuckit/

Fal@yiffit.net on 16 Nov 2023 01:59 collapse

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 on 16 Nov 2023 03:29 next collapse

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 on 16 Nov 2023 15:13 collapse

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).

palebluethought@lemmy.world on 16 Nov 2023 01:54 next collapse

Aren’t checked exceptions in Java generally regarded as a bad mistake?

Nevoic@lemm.ee on 16 Nov 2023 02:46 next collapse

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.

SittingWave@programming.dev on 17 Nov 2023 08:53 collapse

I heard the same, but not sure why. Do you have a link?

getseclectic@sh.itjust.works on 17 Nov 2023 23:43 collapse

This post covers it pretty well phauer.com/2015/checked-exceptions-are-evil/

Maoo@hexbear.net on 16 Nov 2023 07:22 next collapse

My counter: let’s throw Java into a pit

tnuctip@mastodonapp.uk on 16 Nov 2023 15:09 collapse

@Maoo @onlinepersona
That's unfair. Java did everyone a huge favour by giving a practical demonstration of why (mandatory) checked exceptions are awful.

Sigmatics@lemmy.ca on 16 Nov 2023 21:35 next collapse

Yeah, let’s not. This is not a good idea

sugar_in_your_tea@sh.itjust.works on 17 Nov 2023 19:50 collapse

I disagree, I’d instead like to move toward handling errors as logic, and keeping exceptions for actually exceptional cases. If you’re expecting an exception, that’s data.

So here’s my proposal:

  • introduce monads like Maybe/Result that forces the dev to handle expected errors in logic
  • make an easy way to return errors early without interrupting logic flow
  • simplify checking for None values in chaining

For the first (not exactly a monad, may need a new type to wrap things):

def maybe_err(val: int) -> Result[int, ValueError]:
    if val < 0:
        return ValueError("cannot be negative")
    return val

match (val := maybe_err(-1)):
    case int():
    case ValueError():

For the second:

val = maybe_error(-1)?  # special handling to return instances of Error early

And the third:

val = x?.y?.z ?? DEFAULT

I like this much better than having try/except blocks throughout the code, and reserve those only for logging and whatnot at the top level. If you document exceptions, people will use them even more as data instead of exceptions.

So only raise if you want it to bubble all the way up, return errors if it’s just data for the caller. Libraries should almost never raise.

Gallardo994@sh.itjust.works on 18 Nov 2023 04:53 collapse

Anything but over9000 variations of nullables like in C#

sugar_in_your_tea@sh.itjust.works on 18 Nov 2023 14:35 collapse

I’m not too familiar with C# (last used it like a decade ago), but I think the rules here would be pretty simple:

  • x? - if x is None or an Error, return from the function early, otherwise use the value and continue
  • x?.y - same as above, but with an attribute of x
  • x ?? y - instead of returning as in the first, use y as the default value

And maybe add an option to convert exceptions from a function to an Error value (maybe some_func?() to convert to error values? IDK, I haven’t thought through that part as much).

Hopefully that’s simple enough to be useful.

If I were proposing this, I’d limit it to optional chaining since that’s far more annoying to me currently.