On Mon, Oct 24, 2022, 9:03 PM robert engels <reng...@ix.netcom.com> wrote:
> 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.
>
I'm not sure that the problem that you see is a problem that we are
interested in solving. Go is not Java, nor should it be. We already have
Java, and it's a fine language.
In any case it's been years since the Go team has made any proposals
related to error handing.
Ian
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>
> 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
> .
>
>
>
--
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/CAOyqgcVwoujwfrfMyXPMGGs0D89Cw8FURT7GokaJJXxtfqUc%3Dw%40mail.gmail.com.
