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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
