4 ms·

Honestly all I need is Java exceptions without checked exceptions nonsense. Just let me throw exception, collect entire stacktrace, let me catch exception whene

Honestly all I need is Java exceptions without checked exceptions nonsense. Just let me throw exception, collect entire stacktrace, let me catch exception whenever I want or dump stacktrace if nobody caught it and goroutine died. It's simple and it works. Investigate recent Java improvements with stacktrace logging (I think Spring Boot does that, basically it turns stack trace backwards as error cause often is on the last part of stacktrace) and implement as necessary. I love golang as much as I hate its error handling. If not for it, I'd switch to it tomorrow. As it is now, I'd rather bend Java to be golang. Just because of error handling. The only thing that I'd add to Java exceptions is to enrich the exception stacktrace with all serializable local variables on every level (including parameters). Yes, that's a lot of data and some smart approach should be taken to serialize it to string. Basically all "simple" local variables should be included to stacktrace. That'd be another level of error reporting.

jherico 4y ago
Go and Rust both strike me as languages made by people who HATE Java/C++ style exception handling but thought the best way to deal with it was to invent a language that constantly punches you in the face. the fact that the most popular Go IDE actually has logic to automatically fold and hide the constant error handling boilerplate and that people seem to have no problem with that makes me feel like I'm taking crazy pills.
- vore 4y ago
  I feel like Rust isn't too bad at it: if you want the almost C++/Java level of wrist strain just use anyhow::Error, remember to put ? after fallible calls and downcast to extract the underlying error. C++ and Java exceptions have non-local flow and it's hard to determine what function can throw what, so if you do want to add error handling cases you would have to inspect every function to know if it throws or not. Yeah, there's noexcept and checked exceptions but one was a late addition that legacy codebases don't use and the other everyone just does throw new RuntimeException(err) anyway.
  - typical_gopher 4y ago
    > C++ and Java exceptions have non-local flow and it's hard to determine what function can throw what, so if you do want to add error handling cases you would have to inspect every function to know if it throws or not In general I agree with you, but Rust is already having this problem by people making liberal use of unwrap.
    - potatochup 4y ago
      I haven't seen such a problem with unwrap. Newer people use it but are quickly taught to use Err instead. The only times I use it is unreachable!()
  - nyanpasu64 4y ago
    C++ exceptions and Rust Anyhow errors lack stack traces by default, whereas Java exceptions capture them by default, aiding debugging. I'm not sure if Rust spans satisfy the same requirements as stack traces; they seem more built around logging and asynchronous execution, than error handling and synchronous code.
    - jamincan 4y ago
      I believe the backtrace API was added to stable rust with the most recent release, and so anyhow backtraces should now be available outside of nightly.
  - Animats 4y ago
    After several false starts, Rust mostly got this right with returning Result<usefulresult, Error> from most functions, and using "?" for "If the result of this is Error, do a return of the error". There's also a thing where you can write foo().context("useful info about foo")? and pass some more info with the error. Plus, most things that work like "open" close when their scope closes, so you don't need all that "defer" stuff. I would have liked a good error hierarchy like Python 2 had, where there was a clear distinction between program-is-broken errors and errors due to external causes. But Rust didn't get that at the beginning, and now it's too late.
- the_gipsy 4y ago
  Rust did it well, go just didn't. Maybe because go is the new java.
layer8 4y ago
I agree, except that I want checked exceptions. It’s really not different from the error part of an Either return type — and it could be implemented that way on the ABI level. (And I’m not sure about the local variables idea, because that could become really slow and could effectively duplicate the stack in size, or even more in the case of “suppressed” exceptions).
- peterashford 4y ago
  Yeah, it's interesting how some people think that its axiomatic that checked exceptions are so awful where they're a feature I really value. <shrug>
  - vbezhenar 4y ago
    Every modern Java library I’m aware of, avoids checked exceptions. Java itself recently introduced UncheckedIOException to wrap IOException in a few places. So while it’s not an official deprecation, it’s a sign that something’s not quite right. Those are just objective facts. I, personally, don’t like this feature either. May be with very different language design it could be better, but as it is, it’s ergonomics is awful IMO. And I have problems to imagine how to rework it to make it work.
    - kaba0 4y ago
      Well, arguably Java’s implementation is not the best regarding checked exceptions. Nonetheless I feel we threw the baby out with the bath water here, as a non-inheritance based checked exception system was not really tried and I feel it would be the best of both words. Since in the end, checked exceptions are just Result types which happens to be natively “understood” by the language - it gets stack trace support, auto-unwraps and bubbles up.
    - layer8 4y ago
      What's missing in Java is the ability for methods to abstract over the set of exceptions thrown by the methods it calls, via generics, for morethan a single exceptikn type. This would in principle be possible, similar to variadic template parameters in C++, and would solve the problem for lambdas and Streams etc. It's a bummer that Java doesn't provide this at present. Java developers are really divided on the topic of checked exceptions, there is no consensus.
pensatoio 4y ago
In my experience, go developers I've worked with agree that we hate exceptions.
kgeist 4y ago
>Just let me throw exception, collect entire stacktrace, let me catch exception whenever I want or dump stacktrace if nobody caught it and goroutine died. Go allows you to do that with panic/recover, although it's not quite idiomatic
- vbezhenar 4y ago
  With entire standard library that’s not just idiomatic. I would need to write wrappers or just rewrite standard library. It’s plain crazy if you ask me. So yeah, theoretically it’s possible to emulate exceptions, but in reality it’s not.
jayd16 4y ago
Auto-capture during throw is actually a pretty neat idea. Somewhere between usual exceptions and a heap dump.
kaba0 4y ago
Not trying to start a flamewar, but then why don’t just use Java? It is a more concise (seriously), more expressive language with a bigger ecosystem and similar performance (go is better for smaller apps, while java is better for big server workloads). It pretty much already has virtual threads, not much will change regarding its API, so not even that is a difference.

jherico 4y ago

Go and Rust both strike me as languages made by people who HATE Java/C++ style exception handling but thought the best way to deal with it was to invent a language that constantly punches you in the face. the fact that the most popular Go IDE actually has logic to automatically fold and hide the constant error handling boilerplate and that people seem to have no problem with that makes me feel like I'm taking crazy pills.

vore 4y ago
I feel like Rust isn't too bad at it: if you want the almost C++/Java level of wrist strain just use anyhow::Error, remember to put ? after fallible calls and downcast to extract the underlying error. C++ and Java exceptions have non-local flow and it's hard to determine what function can throw what, so if you do want to add error handling cases you would have to inspect every function to know if it throws or not. Yeah, there's noexcept and checked exceptions but one was a late addition that legacy codebases don't use and the other everyone just does throw new RuntimeException(err) anyway.
- typical_gopher 4y ago
  > C++ and Java exceptions have non-local flow and it's hard to determine what function can throw what, so if you do want to add error handling cases you would have to inspect every function to know if it throws or not In general I agree with you, but Rust is already having this problem by people making liberal use of unwrap.
  - potatochup 4y ago
    I haven't seen such a problem with unwrap. Newer people use it but are quickly taught to use Err instead. The only times I use it is unreachable!()
- nyanpasu64 4y ago
  C++ exceptions and Rust Anyhow errors lack stack traces by default, whereas Java exceptions capture them by default, aiding debugging. I'm not sure if Rust spans satisfy the same requirements as stack traces; they seem more built around logging and asynchronous execution, than error handling and synchronous code.
  - jamincan 4y ago
    I believe the backtrace API was added to stable rust with the most recent release, and so anyhow backtraces should now be available outside of nightly.
- Animats 4y ago
  After several false starts, Rust mostly got this right with returning Result<usefulresult, Error> from most functions, and using "?" for "If the result of this is Error, do a return of the error". There's also a thing where you can write foo().context("useful info about foo")? and pass some more info with the error. Plus, most things that work like "open" close when their scope closes, so you don't need all that "defer" stuff. I would have liked a good error hierarchy like Python 2 had, where there was a clear distinction between program-is-broken errors and errors due to external causes. But Rust didn't get that at the beginning, and now it's too late.
the_gipsy 4y ago
Rust did it well, go just didn't. Maybe because go is the new java.

layer8 4y ago

I agree, except that I want checked exceptions. It’s really not different from the error part of an Either return type — and it could be implemented that way on the ABI level. (And I’m not sure about the local variables idea, because that could become really slow and could effectively duplicate the stack in size, or even more in the case of “suppressed” exceptions).

peterashford 4y ago
Yeah, it's interesting how some people think that its axiomatic that checked exceptions are so awful where they're a feature I really value. <shrug>
- vbezhenar 4y ago
  Every modern Java library I’m aware of, avoids checked exceptions. Java itself recently introduced UncheckedIOException to wrap IOException in a few places. So while it’s not an official deprecation, it’s a sign that something’s not quite right. Those are just objective facts. I, personally, don’t like this feature either. May be with very different language design it could be better, but as it is, it’s ergonomics is awful IMO. And I have problems to imagine how to rework it to make it work.
  - kaba0 4y ago
    Well, arguably Java’s implementation is not the best regarding checked exceptions. Nonetheless I feel we threw the baby out with the bath water here, as a non-inheritance based checked exception system was not really tried and I feel it would be the best of both words. Since in the end, checked exceptions are just Result types which happens to be natively “understood” by the language - it gets stack trace support, auto-unwraps and bubbles up.
  - layer8 4y ago
    What's missing in Java is the ability for methods to abstract over the set of exceptions thrown by the methods it calls, via generics, for morethan a single exceptikn type. This would in principle be possible, similar to variadic template parameters in C++, and would solve the problem for lambdas and Streams etc. It's a bummer that Java doesn't provide this at present. Java developers are really divided on the topic of checked exceptions, there is no consensus.

pensatoio 4y ago

In my experience, go developers I've worked with agree that we hate exceptions.

kgeist 4y ago

>Just let me throw exception, collect entire stacktrace, let me catch exception whenever I want or dump stacktrace if nobody caught it and goroutine died. Go allows you to do that with panic/recover, although it's not quite idiomatic

vbezhenar 4y ago
With entire standard library that’s not just idiomatic. I would need to write wrappers or just rewrite standard library. It’s plain crazy if you ask me. So yeah, theoretically it’s possible to emulate exceptions, but in reality it’s not.

jayd16 4y ago

Auto-capture during throw is actually a pretty neat idea. Somewhere between usual exceptions and a heap dump.

kaba0 4y ago

Not trying to start a flamewar, but then why don’t just use Java? It is a more concise (seriously), more expressive language with a bigger ecosystem and similar performance (go is better for smaller apps, while java is better for big server workloads). It pretty much already has virtual threads, not much will change regarding its API, so not even that is a difference.