please replace:
"will return immediately to the [...]"
with
"will jump immediately to the [...]"
(sorry)
On Friday, September 8, 2017 at 4:07:35 PM UTC+10, Dorival Pedroso wrote:
>
> Hi Dave,
>
> The "watch" strategy would, of course, allow us to do the important steps
> you've mentioned (e.g. clean up and so on).
>
> For instance:
> watch err != nil {
> // do the important things
> return err
> }
>
> The watch basically "groups common tasks".
>
> For example, If we have so many tasks, we could do this:
> watch errFiles != nil {
> cleanup() // do cleanups as Dave suggested
> return // this is an synthetic example that doesn't require error
> propagation (application dependent, of course)
> }
> watch errComputations != nil {
> // nothing to be done here
> return errComputations // return the error because computations failed
> }
> errFiles = fileOperation("a.txt") // will return immediately to the first
> "watch" if errFiles != nil
> errFiles = fileOperation("a.txt") // will return immediately to the first
> "watch" if errFiles != nil
> errFiles = fileOperation("a.txt") // will return immediately to the first
> "watch" if errFiles != nil
> errCompuations = computeWith("a.txt") // will return immediately to the
> second "watch" if errComputations != nil
> errCompuations = computeWith("a.txt") // will return immediately to the
> second "watch" if errComputations != nil
> errCompuations = computeWith("a.txt") // will return immediately to the
> second "watch" if errComputations != nil
>
> Of course, we don't need the "watch" command for these. In fact, we need
> nothing special in Go to properly handle these errors.
>
> Cheers.
> Dorival
>
>
>
> On Friday, September 8, 2017 at 1:08:47 PM UTC+10, Dave Cheney wrote:
>>
>>
>>> Wouldn't be great to have a "syntactical sugar" to make things (at least
>>> a little bit) simpler in our beloved Go language?
>>>
>>>>
>>>>
>> no, I don't think so.
>>
>> Something that few in in this thread have focused on is the most
>> important part of the go error handling story happens *before* the `return
>> err` statement
>>
>> if err != nil {
>> // this is the important part
>> return err // this is not
>> }
>>
>> Specifically, when an error occurs, cleaning up the accumulated state to
>> that point, removing any temporary items like files on disk, transactions,
>> etc, so that the caller can attempt to retry the operation if they so
>> choose.
>>
>> Now it happens that most times, thanks to things like defer, there is
>> usually nothing to handle in the cleanup phase before returning the error,
>> but in my opinion does not take anything away from this being the most
>> important part of Go's error handling story.
>>
>
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
