On Mon, Oct 24, 2022 at 8:49 PM Robert Engels <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.
