At the risk of getting caught in the crossfire, I will point out again that
I just found it interesting how close it was possible to get to something
like check/handle with just standard language constructs. If you'll excuse
the cuddled checks, I think this:
func CopyFile(src, dst string) (err error) {
check, done := handle.Errorf(&err, "copy %s %s", src, dst);
defer done()
r, err := os.Open(src); check(err)
defer r.Close()
w, err := os.Create(dst); check(err)
defer handle.Chain(&err, func() {
w.Close()
os.Remove(dst)
})
_, err = io.Copy(w, r); check(err)
return w.Close()
}
looks pretty similar to this:
func CopyFile(src, dst string) error {
handle err {
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
r := check os.Open(src)
defer r.Close()
w := check os.Create(dst)
handle err {
w.Close()
os.Remove(dst) // (only if a check fails)
}
check io.Copy(w, r)
check w.Close()
return nil
}
I'll probably continue playing with this. If others would like to take a
look the code is here:
https://github.com/michaelmacinnis/handle
I'm particularly interested in any problems I may have overlooked and
similar packages that may exist but that I haven't stumbled across.
Thanks,
Michael.
On Thursday, February 18, 2021 at 2:27:33 PM UTC-5 [email protected]
wrote:
> Yes but without robust error information (stack trace, typed error) it is
> very hard to write that top-level handler - at least not a robust one. Plus
> you are relying on the proper use of defer etc up the chain. This is much
> simpler with exceptions - to me anyway.
>
> > On Feb 18, 2021, at 10:39 AM, Kevin Chadwick <[email protected]> wrote:
> >
> >
> >> don’t think ‘single shot, short lived processes’ are the typical Go
> >> paradigm - they are usually larger , multi layer, long lived “server”
> >> processes. It’s my opinion that Gos error handling is a problem for
> >> these types. I am not saying it can’t be done but it’s harder to
> >> design/deliver/maintain.
> >>
> >
> > I can't agree. Long lived go server processes are made of many single
> shot worker tasks that can send errors back just the same.
> >
> >> Exceptions (used properly) provide a lot of information when reading
> >> the code. I don’t get the same feedback with Gos error returns.
> >
> > AFAICT, this is just structuring. There is nothing stopping your server
> processes from having a documented error processor, handling returned error
> types, possibly even from distributed services.
> >
> > The only real difference is if the errors are tunnelled in plain sight
> or behind the scenes. You could store rather than returning errors if you
> wanted to. I don't think Go users should be encouraged to hide errors away.
> >
> > --
> > 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].
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/65F3B450-5507-4E3C-A09B-905DCF4C0006%40gmail.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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/1c510a2c-981b-4980-8f47-7a025769e233n%40googlegroups.com.
