This has been interesting to watch as I too have somehow been "converted" from java style exceptions to current go-style error flow as preference. In the first example you just shared, I think if you elaborate the comments, "at this point all files are open, if any fail, others are closed", you may see "logic" in your exception handler like "if f1 != nil f1.close; if f2 != null f2.close(), etc...". Having an additional logic point seems "less clean" IMHO than handling it one file at a time as it happens. If you wanted to add some context around what is special in file 1 - 3 in that example you could also include it in line vs. as a separate logic tree in the exception handler "config file did not load" vs. "data file", etc..
I had a different similar problem to the multi-file example where "missing" is normal and while solveable if you change your logic to first check file.exists() not having to add a check for something you already get in the error makes the logic simpler on the page. The translation I have become used to is similar to how you started, e.g. Runtime Exception = Panic, Checked Exception = Error. The one part that I do like in what you mention is the explicit errors in the definition which become part of documentation. That does force some good habits that need to be done manually today but can potentially be as simple as a vet check on a future comment style if missing and returns an error type. >From a value standpoint, the incremental benefit of changes to error seems low compared to the other big changes like generics. My .02 if it helps the conversation at all. Sincerely, David On Tuesday, February 23, 2021 at 7:42:25 AM UTC-6 ren...@ix.netcom.com wrote: > The complexity there is from generators + exceptions. I am not proposing > generators for Go as it doesn’t need it. > > On Feb 23, 2021, at 6:03 AM, Nigel Tao <nige...@golang.org> wrote: > > > > If you're proposing exceptions, be aware of how complicated the control > flow for correct handling can be. Look for what follows `The statement > "RESULT = yield from EXPR" is semantically equivalent to...` in > https://www.python.org/dev/peps/pep-0380/ > > -- > > 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/CAOeFMNUEOGf1r-1FpCTFJ0ze9s26ZNqN9vGLGVDoCcaW72%2B9ag%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CAOeFMNUEOGf1r-1FpCTFJ0ze9s26ZNqN9vGLGVDoCcaW72%2B9ag%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/155bf359-2cd3-4d2a-8966-f92d8488426cn%40googlegroups.com.
