Unchecked exceptions in Java denote programming errors or critical unrecoverable errors.
If these are being trapped/handled it is indicative of a system with design errors. (That being said, some programming errors can be ignored/handled at the request level - indicating that the chance any particular request triggers the bug is low). > On Oct 21, 2022, at 2:30 PM, 'Daniel Lepage' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > > > That aspect of this idea seems similar to the try proposal > > (https://go.dev/issue/32437). > > Yes, I read over that proposal and the comments; it seemed like the biggest > objections were: > 1. handle() is very similar to defer/recover but not quite the same, which > could be confusing (e.g. that a defer() inside a block is just a normal > defer, while a handle() inside a block does not apply outside of that block) > 2. It's confusing to take the previous if err != nil {} blocks that were > obviously in response to the preceding line and have the actual handling code > be earlier and far away, and > 3. It would encourage people to just pass errors up without modification, > because it's easier to just add a bunch of try's to your code and use the > default handler. > > My proposal doesn't have these issues - the handler goes with the try block > so there's no separate function being deferred and no ambiguity about what > code a given handler applies to, the handle block always comes right after > the block being try'd, and there is no "default handler" - you can't use > check to avoid having any error handling, only to consolidate several error > handlers that would be identical. > > > In that issue there was considerable resistance to having flow of control > > change as part of an expression. No other part of Go works that way: flow > > of control change is always a keyword, or a call to panic which can only > > occur in statement context. > > This is not true - testing.TB.Fatal, log.Fatal, etc. affect control flow, as > do numerous expressions like nil dereferences or zero divisions, and of > course any function call that triggers any of those (and in extreme cases > like running out of memory practically ANY expression could trigger a control > flow change). > > The link I provided earlier to the Ondatra package demonstrates that > real-world Go programmers already ARE using expressions for control flow, by > (in this example) calling functions that take a testing.TB and call t.Fatal() > if anything goes wrong; the authors clearly decided that this was more > readable than using idiomatic error handling. > > I see panic/TB.Fatal as being somewhat analogous to Java's unchecked > exceptions: they change control flow without warning and you can't be sure > what functions trigger them. Errors-as-return-values is analogous to checked > exceptions: you explicitly mark things you know could go wrong and the > compiler will yell at you if you don't address those possibilities. Java's > single biggest mistake (IMO) was making unchecked exceptions easier to use > than checked exceptions - as a result many developers just didn't do any > error handling at all. Go has mostly avoided this because checking errors is > usually easier to write and read than using any of the aforementioned > unchecked methods, but the t.Fatal examples make it clear that there still > are cases where unchecked errors make code easier to read and write. I'm > proposing to fix that, not by making unchecked errors harder to use or by > turning checked errors into unchecked ones, but rather by streamlining the > worst cases in proper error checking, primarily the all-too-common case where > "if ComputeSomething(t, FetchThingOne(t), FetchThingTwo(t)) > 1" is so, so > much easier to read and write than the equivalent properly checked version > (which requires many more lines and several extra variables). > > Dan > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAAViQtjfE2FdauJ888bu1HC%2BZPPCiff5Bz5_N%3DeM2%3DVtx2fFsg%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/06DD1147-DBE3-4794-85B4-61019BBE1A40%40ix.netcom.com.
