I’ll only add to this, there is no reason to close in the exception handler - it is automatic by the try-with-resource. The only reason to check null is if you needed to “do something else” based on that state.
I think a better pattern with the “something else” is to always use standard wrappers on the common resources so that try-with-resource is as simple as possible. > On Feb 23, 2021, at 1:02 PM, da...@suarezhouse.net <da...@suarezhouse.net> > wrote: > > 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 >> <applewebdata://45C62E4D-0334-4395-AD30-D44BCF582963>> 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/ >> <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 >> <applewebdata://45C62E4D-0334-4395-AD30-D44BCF582963>. > >> 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 > <mailto: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 > > <https://groups.google.com/d/msgid/golang-nuts/155bf359-2cd3-4d2a-8966-f92d8488426cn%40googlegroups.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/47E656C5-1AD9-4EE5-936D-023C59C9696D%40ix.netcom.com.
