241–250 of 297 posts
Earlier quoted context omitted.
How would you define f in a different language such that f(g()) worked? You couldn’t do that in Go, for instance.
There's at least one language, Koka ( https://koka-lang.github.io/koka/doc/book.html ) that has effects in its type system. There are probably others. If you don't have effects, you could use union types.
Earlier quoted context omitted.
... not sure if serious or not
I'm completely serious in the sense that you could do that and really would in some situations. You might do it because you want to factor the handling of the different result cases out to another function.
Earlier quoted context omitted.
You can also rethrow checked exceptions as runtime exceptions by exploiting type erasure: public static RuntimeException unchecked(Exception e) { Exceptions. throw_checked(e); return null; } private static void throw_checked(Exception e) throws E { throw (E) e; } then you can do this: try { ... } catch (IOException e) { throw unchecked(e); } And the original exception is thrown without being wrapped. It's as though y…
There's one big problem with this approach. You can't catch checked exception if the try-block does not throw it (according to compiler). That's compiler error. So yes, you can throw IOException masking it to RuntimeException, however you can't catch it later without another gimmicks like catching Exception and checking if it's IOException (and even that check causes linter warnings in Idea, so now you need to suppre…
Earlier quoted context omitted.
In practice there is a lot of paths that you don't want to "crash" on, but try the next thing etc.
Don't model those as Exceptions, because they are not exceptional. They are control flow.
you basically end up needing to write your api twice.
Earlier quoted context omitted.
I think the way Go does error handling is the best compromise.
It's one of the worst I've seen. It adds so much cognitive overhead to reading the code and makes it more annoying to write. Every function call that can fail is followed by 3 lines to check for and return the error. The actual logic quickly gets lost in there. If it wasn't for the error handling, I would probably use Go for some of my projects. It compiles to a native, self-contained binary and still has the conveni…
Earlier quoted context omitted.
I think the way Go does error handling is the best compromise.
It’s honestly the worst compromise. You can trivially ignore any error in Go and they don’t contain contextual information about the call stack.
This exception is a {@link RuntimeException} because it is exposed to the client. Using a {@link RuntimeException} avoids bad coding practices on the client side where they catch the exception and do nothing. It is often the case that you want to blow up if there is a parsing error (i.e. often clients do not know how to recover from a {@link JsonParseException}.
When I write code in C#, I always left wondering: Does this method throw an exception (ignoring null pointer and invalid arguments)? It bothers me. And, I write that as someone who really likes C# -- it's a great language for my needs.
And, yes, I can appreciate that many people don't like the friction associated with checked exceptions. It does add a lot of visual bloat! Serious question: What are the alternatives that _communicate sufficiently_ through an interface? Honestly, I struggle to think of a better alternative, so I just live with it.
Just like the bad old days of integer return values used to indicate error state (C-like languages), you need to check every single call -- there are no shortcuts, especially with I/O. For me, it is similar with Java and C# when writing I/O code: You need to catch and correctly handle every (checked-ish) exception.
Earlier quoted context omitted.
Lets be honest. The more likely thing is that either the coworker would use an unchecked exception or that they would change the callsite to: try { theUpdatedFunction(); } catch (MyNewCheckedException e) { logger.warn("Whoopsie doopsie", e) throw new SomeUncheckedException("Something failed, idk", e) } Which really is a zero sum game. The code still breaks the same way, but the checked exception gets eventually wrapp…
If the Future, Executor, Optional, Streams, etc played nice with checked exceptions it would probably be different. Right now at some point you do have to wrap it into an unchecked exception.
Reading through the comments, I realize this may be a minority view - but I like coding for the happy path and letting exceptional states crash. I find languages like go a bit harder to parse quickly because I always have to "unwrap" the happy path from all of the mixed in error handling. I'm sure I'd get used to it eventually, but I like that unchecked exceptions in Java are now an option!
If it's some random web backend, it's often fine to just let the error propagate as a 5xx. Many error cases wouldn't have a better solution anyway, and all that's breaking is a single page or resource load. (Of course on the frontend it might be nicer to show some kind of an error than just e.g. having frontend functionality silently fail.)
If it's a desktop application and you're crashing the entire application because wifi happened to drop or whenever there's anything your happy path didn't predict, that's going to be bad.
If it's some kind of an embedded thing and you're crashing an entire device because you didn't bother to handle cases that are outside of the happy path but entirely possible, I only hope it's not something important you're developing.