3 ms·

This is an old suggestion. You don't have the slightest idea what kind of rabbit holes this will lead into. This has been discussed time and time again. The mu

This is an old suggestion. You don't have the slightest idea what kind of rabbit holes this will lead into. This has been discussed time and time again. The much better approach is to keep it as-is but make Exceptions composable: switch( this.networkOperation() ) case throws IOException ex -> "invalid" case String expected -> return expected; case Object obj -> throws new IllegalArgumentException(obj); You get the best of both worlds. The caller is forced to handle expected errors at call-site (aka, where you have the most information). But you can still delegate the error to a higher level, such as Controllers where the error gets turned into a "500 Server Error". The problem really only is that you are currently forced into creating a new try-catch block. If that goes away, you are essentially dealing with sum-types. This will be more elegant than heralded languages such as Go where you slavishly write "err != nil" statements at every turn.

stickfigure 2y ago
This doesn't seem any different from try/catch? The syntax differences are minimal. I don't mind try/catch, but I agree that checked exceptions should be dropped. Exceptions are for exceptional situations, which are myriad and rarely need to be handled except at some upper level (return 500, show error dialog, etc).
- ivan_gammel 2y ago
  Oh, that actually does look different. Switch expression with exceptions would allow compact use of checked exceptions in method chaining. List<URI> pages… var content = pages.stream().map(uri -> switch(fetch(uri)) { case Page model -> return model; case throws IOException -> return Page.notFound(uri); }).toList();
derriz 2y ago
"You don't have the slightest idea what kind of rabbit holes this will lead into." Instead of making assumptions about what I know or don't know about programming language theory and type systems, could you list these rabbit holes? Java inspired languages like Kotlin, Scala and C# all considered checked exceptions and all decided to drop them and I've never heard users of any of these language express any wish to re-introduce them. I've used all three professionally and I have no idea what "rabbit holes" you're talking about? In fact there isn't a single widely used language besides Java that feature checked exceptions. Arguably Eiffel had them but that's seriously stretching the definition of "widely used".
- m11a 2y ago
  > In fact there isn't a single widely used language besides Java that feature checked exceptions. Not in Java's form, but I'd argue Rust's Result type basically achieves the same effect but with less syntax. A function call can return an error variant, and the caller must handle the case (even if that's just propagating it up with `?`), as opposed to letting it silently flow up the call stack (which is more like a Rust panic). And I'd argue that Rust's error handling is excellent. The programmer is always forced to acknowledge function calls which may produce an error, yet is also able to say "I don't care" without much syntactic overhead.

stickfigure 2y ago

This doesn't seem any different from try/catch? The syntax differences are minimal. I don't mind try/catch, but I agree that checked exceptions should be dropped. Exceptions are for exceptional situations, which are myriad and rarely need to be handled except at some upper level (return 500, show error dialog, etc).

ivan_gammel 2y ago
Oh, that actually does look different. Switch expression with exceptions would allow compact use of checked exceptions in method chaining. List<URI> pages… var content = pages.stream().map(uri -> switch(fetch(uri)) { case Page model -> return model; case throws IOException -> return Page.notFound(uri); }).toList();

derriz 2y ago

"You don't have the slightest idea what kind of rabbit holes this will lead into." Instead of making assumptions about what I know or don't know about programming language theory and type systems, could you list these rabbit holes? Java inspired languages like Kotlin, Scala and C# all considered checked exceptions and all decided to drop them and I've never heard users of any of these language express any wish to re-introduce them. I've used all three professionally and I have no idea what "rabbit holes" you're talking about? In fact there isn't a single widely used language besides Java that feature checked exceptions. Arguably Eiffel had them but that's seriously stretching the definition of "widely used".

m11a 2y ago
> In fact there isn't a single widely used language besides Java that feature checked exceptions. Not in Java's form, but I'd argue Rust's Result type basically achieves the same effect but with less syntax. A function call can return an error variant, and the caller must handle the case (even if that's just propagating it up with `?`), as opposed to letting it silently flow up the call stack (which is more like a Rust panic). And I'd argue that Rust's error handling is excellent. The programmer is always forced to acknowledge function calls which may produce an error, yet is also able to say "I don't care" without much syntactic overhead.