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.
> 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/19573C66-1957-4F12-A2C4-F6CB9B4A5CD2%40ix.netcom.com.
