There's no crossfire :)
I think most of the issues I have can probably be addressed with some
standardized packages without converting panic/recover into full-blown
exceptions and making them the default. The key is “standardized”, which is why
I’m sad to see lack of progress towards a new paradigm for Go2.
> On Feb 18, 2021, at 6:01 PM, Michael MacInnis <michael.p.macin...@gmail.com>
> wrote:
>
> 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
> <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 ren...@ix.netcom.com 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 <m8il...@gmail.com
> > <applewebdata://A8DBF130-556C-433B-9A49-E9E80FEA1074>> 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 golang-nuts...@googlegroups.com
> > <applewebdata://A8DBF130-556C-433B-9A49-E9E80FEA1074>.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/golang-nuts/65F3B450-5507-4E3C-A09B-905DCF4C0006%40gmail.com
> >
> > <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 golang-nuts+unsubscr...@googlegroups.com
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/1c510a2c-981b-4980-8f47-7a025769e233n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/golang-nuts/1c510a2c-981b-4980-8f47-7a025769e233n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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/3C6D4163-655A-47F2-B655-6D79D8B18BDC%40ix.netcom.com.
