Totally understandable, but then I think the Go team should also drop any proposals related to “improved error handling” - because you are going to arrive back where you started - maybe with the a slightly different syntax and that hardly seems worth the effort. Great engineering is built by standing on the shoulders of giants. I haven’t seen any arguments that refute their findings.
> On Oct 24, 2022, at 10:52 PM, Ian Lance Taylor <i...@golang.org> wrote: > > On Mon, Oct 24, 2022 at 8:49 PM Robert Engels <reng...@ix.netcom.com > <mailto:reng...@ix.netcom.com>> wrote: >> >> I’ve read that many times and I don’t believe it holds much water. Even the >> example cited about handling the inability to open a file - the function >> can’t handle this because it does not know the intent which leads to the >> >> If err != nil { >> return err >> } >> >> boilerplate. This is exactly what checked exceptions are designed to address. >> >> Sure, it you don’t properly decompose your functions the Go error handling >> makes this safer, but properly decompose the functions and checked >> exceptions make things far far easier. > > Thanks, but this has been discussed at great length in the past. We > don't need to rehash yet again. > > Ian > > > >>> On Oct 24, 2022, at 10:28 PM, Ian Lance Taylor <i...@golang.org> wrote: >>> >>> On Mon, Oct 24, 2022 at 5:57 PM Robert Engels <reng...@ix.netcom.com> >>> wrote: >>>> >>>> But that highlights the value of exceptions - the non error path is very >>>> clean. For example when writing a file - it often doesn’t matter the >>>> reason it failed within the write function - could be an invalid path, >>>> illegal file name , out of disk space. If the code is properly decomposed >>>> that function can’t handle it - so it throws - and hopefully a higher >>>> level function is able to cope (by handling the specific exception) - >>>> maybe asking the user for a different file name or a different destination >>>> device. >>>> >>>> And the writing function can easily cleanup any temp state due to the >>>> stack unwinding and AutoClosable, etc. >>> >>> I did not mean to imply that that was the only consideration for error >>> handling. >>> >>> Go style is to avoid exceptions for other reasons >>> (https://go.dev/doc/faq#exceptions). >>> >>> Ian >>> >>> >>>>>> On Oct 24, 2022, at 6:18 PM, Ian Lance Taylor <i...@golang.org> wrote: >>>>> >>>>> On Sun, Oct 23, 2022 at 9:31 PM 'Daniel Lepage' via golang-nuts >>>>> <golang-nuts@googlegroups.com> wrote: >>>>> >>>>> ... >>>>> >>>>> >>>>>> 3. Streamlining shouldn't only apply to error handling that terminates >>>>>> the function. >>>>>> >>>>>> Unlike panics, errors are values, and should be treated as such, which >>>>>> means that the calling function should be able to decide what to do, and >>>>>> this should include continuing. Frequently it won't - a lot of error >>>>>> handling is just return fmt.Errorf("more context %w", err) - but any >>>>>> proposal that assumes that it *always* won't is, IMO, confusing errors >>>>>> with panics. This is the question that first started this thread - I >>>>>> didn't understand why all the existing error proposals explicitly >>>>>> required that a function terminate when it encounters an error, and >>>>>> AFAICT the answer is "because people are used to thinking of errors more >>>>>> like panics than like return values". >>>>> >>>>> For what it's worth, I see this differently. The existing language is >>>>> not going to go away, and it's pretty good at handling the cases where >>>>> an error occurs and the function does not return. Those cases are by >>>>> their nature all distinct. They are not boilerplate. The way we >>>>> write them today is fine: easy to read and not too hard to write. >>>>> When people writing Go complain about error handling, what they are >>>>> complaining about is the repetitive boilerplate, particularly "if err >>>>> != nil { return nil, err }". If we make any substantive changes to >>>>> the language or standard library for better error handling, that is >>>>> what we should address. If we can address other cases, fine, but as >>>>> they already work OK they should not be the focus of any substantive >>>>> change. >>>>> >>>>> >>>>>> Is part of the problem that the discussion around the >>>>>> try/check/handle/etc. proposals got so involved that nobody wants to >>>>>> even consider anything that looks too similar to those? Would it be more >>>>>> palatable if I proposed it with names that made it clearer that this is >>>>>> about the consolidation of error handling rather than an attempt to >>>>>> replace it entirely? >>>>>> >>>>>> onErrors { >>>>>> if must Foo(must Bar(), must Baz()) > 1 { >>>>>> ... >>>>>> } >>>>>> } on err { >>>>>> ... >>>>>> } >>>>> >>>>> While error handling is important, the non-error code path is more >>>>> important. Somebody reading a function should be able to easily and >>>>> naturally focus on the non-error code. That works moderately well >>>>> today, as the style is "if err != nil { ... }" where the "..." is >>>>> indented out of the normal flow. It's fairly easy for the reader to >>>>> skip over the error handling code in order to focus on the non-error >>>>> code. A syntactic construct such as you've written above buries the >>>>> lede: what you see first is the error path, but in many cases you >>>>> actually want to focus on the non-error path. >>>>> >>>>> Ian >>>>> >>>>> -- >>>>> 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/CAOyqgcXHaQk9TfuAz-TUFCsz_-0kDKa_14f3gYER2ufHbhM73Q%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/CAOyqgcUBs8UWdHMji-gLK0Z_Lt1mZ59tFaK9YT3UzEQ%2BPYKU8A%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/CAOyqgcUDCMegGnDHJRxqwBnqt3jaEtCoXJJ9LYFP0kGCbj0Yvw%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUDCMegGnDHJRxqwBnqt3jaEtCoXJJ9LYFP0kGCbj0Yvw%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/9853839F-86E4-4B82-A02D-D53CDFB1197A%40ix.netcom.com.
