4 ms·

Agreed and even more heretical from me is that I quite like declared exceptions. It makes the interface of a method clear in all the ways it can fail and you ca

Agreed and even more heretical from me is that I quite like declared exceptions. It makes the interface of a method clear in all the ways it can fail and you can directly choose what to handle often without having to look at the docs to work out what they mean, because the names tell you what you need to know. You can ignore them and rethrow catch globally but you can also handle them. Having used Go for years now frankly I prefer exceptions, way too often there is nothing that can be done about an error locally but it produces noise and if branches all over the code base and its even worse to add an error later to a method than in Java because every method has to have code added not just a signature change. I really miss stack traces and the current state of the art in Go has us writing code to produce them in every method.

bigstrat2003 1y ago
Yep, checked exceptions are the shit. You can of course abuse them to create a monstrosity (as you can with anything), but when used responsibly I think they are by far the best error handling paradigm.
- vips7L 1y ago
  I agree but I still think checked exceptions, at least in Java, need more investment syntactically. They’re really painful with lambdas and you need to do weird things to get them to work properly; like rethrowing and catching some unchecked type. Scala has some interesting research here and describe the problem well [0]. Some other things I think that would go a long way to making checked exceptions more usable would be making try as an expression like in Scala or Kotlin. Not being an expression makes for some really awkward code or giant try blocks where you can’t tell what actually errors. Finally we really need a way to “uncheck” them unceremoniously. This is one of the largest reasons developers have rejected them. If you can’t possibly handle something you need to write at least 5-6 lines of code to wrap and throw in a runtime exception or you see developers checking things that they can’t handle and then their callers who also can’t handle those exceptions have to deal with the ceremony of unchecking. I’d really love for some `throws unchecked` or try! syntax that would just automatically turn something into a runtime exception: B func() throws AException; var b = try! func(); This all of course is probably a pipe dream, the OpenJdk team seems to be indefinitely stuck pouring all resources into Valhalla. [0] https://docs.scala-lang.org/scala3/reference/experimental/canthrow.html https://docs.scala-lang.org/scala3/reference/experimental/ca...
delifue 1y ago
Go keeps on not adding syntax sugar for if err != nil. https://go.dev/blog/error-syntax https://go.dev/blog/error-syntax But often the problem of language can be partially solved by IDE. IDE can already generate if err != nil branches. Goland can fold if err != nil branches. https://github.com/golang/vscode-go/issues/2311 https://github.com/golang/vscode-go/issues/2311
9rx 1y ago
> I really miss stack traces What's to miss? Go has exception handlers and stack traces built-in and has had since day one. Even the standard library does it (e.g. encoding/json), if it is that you were waiting on some kind of "blessed permission" to proceed. Exception handling isn't appropriate for every situation (no tool is appropriate for every situation), but if it is for the kinds of problems you have, use it. The tools are there to use.
retrodaredevil 1y ago
Checked exceptions you cannot handle in Java are designed to be caught and rethrown (usually wrapped in your own specific checked exception or some runtime exception). Proper exception handling in Java can feel verbose. In general you should not be adding checked exceptions to method signatures to make the compiler happy. You should be catching them and rethrowing if you cannot handle them.

bigstrat2003 1y ago

Yep, checked exceptions are the shit. You can of course abuse them to create a monstrosity (as you can with anything), but when used responsibly I think they are by far the best error handling paradigm.

vips7L 1y ago
I agree but I still think checked exceptions, at least in Java, need more investment syntactically. They’re really painful with lambdas and you need to do weird things to get them to work properly; like rethrowing and catching some unchecked type. Scala has some interesting research here and describe the problem well [0]. Some other things I think that would go a long way to making checked exceptions more usable would be making try as an expression like in Scala or Kotlin. Not being an expression makes for some really awkward code or giant try blocks where you can’t tell what actually errors. Finally we really need a way to “uncheck” them unceremoniously. This is one of the largest reasons developers have rejected them. If you can’t possibly handle something you need to write at least 5-6 lines of code to wrap and throw in a runtime exception or you see developers checking things that they can’t handle and then their callers who also can’t handle those exceptions have to deal with the ceremony of unchecking. I’d really love for some `throws unchecked` or try! syntax that would just automatically turn something into a runtime exception: B func() throws AException; var b = try! func(); This all of course is probably a pipe dream, the OpenJdk team seems to be indefinitely stuck pouring all resources into Valhalla. [0] https://docs.scala-lang.org/scala3/reference/experimental/canthrow.html https://docs.scala-lang.org/scala3/reference/experimental/ca...

delifue 1y ago

Go keeps on not adding syntax sugar for if err != nil. https://go.dev/blog/error-syntax https://go.dev/blog/error-syntax But often the problem of language can be partially solved by IDE. IDE can already generate if err != nil branches. Goland can fold if err != nil branches. https://github.com/golang/vscode-go/issues/2311 https://github.com/golang/vscode-go/issues/2311

9rx 1y ago

> I really miss stack traces What's to miss? Go has exception handlers and stack traces built-in and has had since day one. Even the standard library does it (e.g. encoding/json), if it is that you were waiting on some kind of "blessed permission" to proceed. Exception handling isn't appropriate for every situation (no tool is appropriate for every situation), but if it is for the kinds of problems you have, use it. The tools are there to use.

retrodaredevil 1y ago

Checked exceptions you cannot handle in Java are designed to be caught and rethrown (usually wrapped in your own specific checked exception or some runtime exception). Proper exception handling in Java can feel verbose. In general you should not be adding checked exceptions to method signatures to make the compiler happy. You should be catching them and rethrowing if you cannot handle them.