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.
> 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/14D51D2A-193D-442F-95C1-592DE7AA4BE7%40ix.netcom.com.
