Exception based error handling is so bad and unsafe that adopting functional error handling with Either, Try etc as implemented by functional addon libraries for many languages, while not yet common, in time it will become the new default even in OO languages. (just like it's been the default in functional languages for decades) Functional error handling types are much simpler, safer and more powerful. Simpler becaus…
Unchecked Java: Say goodbye to checked exceptions
51–60 of 297 posts
Re: Unchecked Java: Say goodbye to checked exceptions
#52Exception based error handling is so bad and unsafe that adopting functional error handling with Either, Try etc as implemented by functional addon libraries for many languages, while not yet common, in time it will become the new default even in OO languages. (just like it's been the default in functional languages for decades) Functional error handling types are much simpler, safer and more powerful. Simpler becaus…
> Safer because unlike exceptions, they force callers to handle all potential outcomes, but no more. Which is bad. In 99% of cases I have no specific error handling for the given problem. Just let the process crash or be handled by application server / framework. Representing these kinds of error conditions in the code which I have no interest in handling is just noise.
> I have no specific error handling for the given problem
then pass it on and decide what to do with it at the system boundary
in the db:
fun getUser(uuid: UUID) : Either
middle layers: pass around the either, you can map, flatmap etc on it to chain it with other computations there
then in the resource layer
return user .fold({ error -> when(error) { is DbError -> HttpResponse.InternalServerError() is UserNotFoundError -> HttpResponse.NotFound } }, { user -> HttpResponse.ok(user) })
Then, at every layer, each method explicitly says in the method signature what it returns. There’s no need to look around each and every line of every method in every layer, or in the framework, or some global exception handler, to figure out what will happen. Developers can tell from a glance at the resource method what the endpoint will return for each outcome, in context.
Things like being unable to communicate with the DB or not finding a user are not exceptional, they're entirely expectable when you're calling a db to look for a user and should be modeled accordingly.
Re: Unchecked Java: Say goodbye to checked exceptions
#53I actually quite like checked exceptions, and miss them in other languages. My biggest gripe with exceptions is that a few calls deep, you can no longer tell whether calling something might throw or not, and what type of exception it might potentially throw.
Re: Unchecked Java: Say goodbye to checked exceptions
#54Earlier quoted context omitted.
Exactly, C++ exceptions are horrible, you never know what throws what. Java made C++ exceptions better by making them explicit, so you always know what throws. Then Kotlin came and made everything a unusable mess (don't get me wrong, I love Kotlin, just hate that it doesn't have explicit exceptions). I honestly think the best error handling strategy is employed by Zig, then Rust. they're very explicit while not getti…
As far as I know Zig errors can't carry any data along. It's nice having more details available about the failure. Take for example if you call to an OS API and it returns an error that wasn't documented to be returned from that function. You can't return that code up the callstack using Zig's error mechanism. Instead there's functions such as unexpectedErrno and unexpectedError. Those call the appropriate method to…
Re: Unchecked Java: Say goodbye to checked exceptions
#55Exception based error handling is so bad and unsafe that adopting functional error handling with Either, Try etc as implemented by functional addon libraries for many languages, while not yet common, in time it will become the new default even in OO languages. (just like it's been the default in functional languages for decades) Functional error handling types are much simpler, safer and more powerful. Simpler becaus…
Exceptions are not unsafe. That said, not modelling them in the type system is a mistake. But the model has to be useful - knowing what functions can or cannot throw is useful, knowing what they throw, less so. (They are safe because of try-finally / try-with-resources)
Re: Unchecked Java: Say goodbye to checked exceptions
#56This seems like a major improvement for Java readability as shown by the examples. What I don't like is the examples of having to use Maven or Gradle to install it. Why does that have to be so verbose, and something written in another language?
Re: Unchecked Java: Say goodbye to checked exceptions
#57Allowing unchecked exceptions in languages without explicit error handling or the return of error values is a mistake IMO! Makes it impossible to call a function safely
Re: Unchecked Java: Say goodbye to checked exceptions
#58Exception based error handling is so bad and unsafe that adopting functional error handling with Either, Try etc as implemented by functional addon libraries for many languages, while not yet common, in time it will become the new default even in OO languages. (just like it's been the default in functional languages for decades) Functional error handling types are much simpler, safer and more powerful. Simpler becaus…
Exception based error handling is unsafe when they are unchecked exceptions. Checked exceptions however are as safe as Either, Try, Monads, Applicatives or whatever. You are forced to declare them in your method signature, the caller is forced to either handle them or rethrow them + declare them as well. And I guess this is precisely why so many developers hate them; they don't like the extra work they have to do to…
No. If I add a checked UserNotFound exception to a getUser db call, you can bet someone higher up the stack will do try catch Exception e, so now they're catching OutOfMemory and who knows what else.
Re: Unchecked Java: Say goodbye to checked exceptions
#59Earlier quoted context omitted.
> Safer because unlike exceptions, they force callers to handle all potential outcomes, but no more. Which is bad. In 99% of cases I have no specific error handling for the given problem. Just let the process crash or be handled by application server / framework. Representing these kinds of error conditions in the code which I have no interest in handling is just noise.
The problem with that is you lose all ability to understand or control what a given endpoint will return in any given situation > I have no specific error handling for the given problem then pass it on and decide what to do with it at the system boundary in the db: fun getUser(uuid: UUID) : Either middle layers: pass around the either, you can map, flatmap etc on it to chain it with other computations there then in t…
Why? In the simplest (but pretty common) case it's:
- successful response
- generic error message
> then pass it on and decide what to do with it at the system boundary
Yes, but if in 99% of cases I only pass it on, it's just visual noise. Noise you become blind to, and it loses meaning.
> Developers can tell from a glance at the resource method what the endpoint will return for each outcome, in context.
They can't really because you end up with some very generic error type anyway. Any typical service can have IOError, DBConnectionError, SQLError, OutOfMemoryError, StackOverflowError plus many other application specific errors. You end up with bulk of your methods returning Either which is then meaningless.
Re: Unchecked Java: Say goodbye to checked exceptions
#60Earlier quoted context omitted.
> Checked exceptions are exactly analogous of Result/Either types. No, they aren't. They are not compositional. You may want to write `f(g())` but there's no way to write the parameter type of `f` to make this work (in Java). That's because checked exceptions are an "effect" that would require extending the Java type system.
Read my last paragraph.