3 ms·

It's quite trivial to write a generic function that handles a particular exception else returns a default value, which addresses the above scenario. final

by azth 5y ago

It's quite trivial to write a generic function that handles a particular exception else returns a default value, which addresses the above scenario. final var x = getOrDefault(C::foo, Something.class, quux()); return x.bar(); And now with pattern matching in Java, it's trivial to write something similar to Rust's/Scala's `Result<T, E>`/`Try<T>` types and be explicit about all exceptions. I haven't compiled the following, but it's along the lines of: final var x = switch (foo()) { case Ok(var r) -> r; case Error e -> quux(); } return x.bar();

morelisp 5y ago
Neither of those is equivalent to what I wrote (in different ways!), and the first one doesn't even work because of type erasure - you can't write generic functions over exception types. You're also focused way too much on the specific lines I wrote and not the general pattern that leads to exception over-handling. > trivial... trivial Rethink your use of this word. Anyway, alternative proposals don't really matter - I could also offer patterns for Go which make accidentally ignoring error values more difficult. We're talking about actually extant code, and nobody writes Java (or Go) like that outside of forum arguments.
- azth 5y ago
  > and the first one doesn't even work because of type erasure - you can't write generic functions over exception types. It sure does work :-) @FunctionalInterface interface ThrowingSupplier<R, E extends Exception> { R get() throws E; } static <T, E extends Exception> T getOrDefault(ThrowingSupplier<T, E> f, Class<E> exceptionType, T def) throws E { try { return f.get(); } catch (Exception e) { if (exceptionType.isInstance(e)) { return def; } throw e; } } > and nobody writes Java (or Go) like that outside of forum arguments. https://www.javadoc.io/doc/io.vavr/vavr/0.9.3/io/vavr/control/Either.html https://www.javadoc.io/doc/io.vavr/vavr/0.9.3/io/vavr/contro... And now that Java has sealed types and pattern matching, it might become more popular. Kotlin already has them (even without the exhaustive pattern matching that Java has): https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-result/ https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-result/
  - morelisp 5y ago
    > It sure does work :-) That you've marked the function `throws E` is an admission it doesn't really work; that's the one exception type it definitely doesn't throw. (Default handling is also still different than the starting point.) Please just stop trying to show off how much you know when I'm trying to discuss how programs in general are actually implemented. You're very clever, but part of why you keep getting it slightly wrong is because probably you don't even write error handling like this day to day.
    - azth 5y ago
      > That you've marked the function `throws E` is an admission it doesn't really work Correct, I didn't spend a lot of time refining it. I suppose the only way to make it work is to remove `throws E` from the signature and make it `throw new RuntimeException(e)`, and be similar to C#/Kotlin/Scala. My last JVM job used Scala, and we wrote things that are similar to val x = foo() match { case Success(res) => res case Error(e) => return quux() // Returns from function scope }

by azth 5y ago

morelisp 5y ago

Neither of those is equivalent to what I wrote (in different ways!), and the first one doesn't even work because of type erasure - you can't write generic functions over exception types. You're also focused way too much on the specific lines I wrote and not the general pattern that leads to exception over-handling. > trivial... trivial Rethink your use of this word. Anyway, alternative proposals don't really matter - I could also offer patterns for Go which make accidentally ignoring error values more difficult. We're talking about actually extant code, and nobody writes Java (or Go) like that outside of forum arguments.

azth 5y ago
> and the first one doesn't even work because of type erasure - you can't write generic functions over exception types. It sure does work :-) @FunctionalInterface interface ThrowingSupplier<R, E extends Exception> { R get() throws E; } static <T, E extends Exception> T getOrDefault(ThrowingSupplier<T, E> f, Class<E> exceptionType, T def) throws E { try { return f.get(); } catch (Exception e) { if (exceptionType.isInstance(e)) { return def; } throw e; } } > and nobody writes Java (or Go) like that outside of forum arguments. https://www.javadoc.io/doc/io.vavr/vavr/0.9.3/io/vavr/control/Either.html https://www.javadoc.io/doc/io.vavr/vavr/0.9.3/io/vavr/contro... And now that Java has sealed types and pattern matching, it might become more popular. Kotlin already has them (even without the exhaustive pattern matching that Java has): https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-result/ https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-result/
- morelisp 5y ago
  > It sure does work :-) That you've marked the function `throws E` is an admission it doesn't really work; that's the one exception type it definitely doesn't throw. (Default handling is also still different than the starting point.) Please just stop trying to show off how much you know when I'm trying to discuss how programs in general are actually implemented. You're very clever, but part of why you keep getting it slightly wrong is because probably you don't even write error handling like this day to day.
  - azth 5y ago
    > That you've marked the function `throws E` is an admission it doesn't really work Correct, I didn't spend a lot of time refining it. I suppose the only way to make it work is to remove `throws E` from the signature and make it `throw new RuntimeException(e)`, and be similar to C#/Kotlin/Scala. My last JVM job used Scala, and we wrote things that are similar to val x = foo() match { case Success(res) => res case Error(e) => return quux() // Returns from function scope }