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.
