Comparing 'panic' and 't.Fatal', they are similar in that there's no notion of recovering and making further progress, they abruptly terminate the process. Still, a wonky thing to say is that a 't.Fatal' call is completely legitimate as a form of "checked"-style error handling. It will log what went badly rather and prevents further tests from running. This is a reasonable application-level behavior for testing (for non-fatal intent, 't.Error' is available).
On Friday, October 21, 2022 at 2:17:07 PM UTC-7 ren...@ix.netcom.com wrote: > 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 < > golan...@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...@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 > > <https://groups.google.com/d/msgid/golang-nuts/CAAViQtjfE2FdauJ888bu1HC%2BZPPCiff5Bz5_N%3DeM2%3DVtx2fFsg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- 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/c72b07e4-de52-4d1f-b964-a506a691c4e8n%40googlegroups.com.
