I think trying to write Python in Go is problematic. You say you intentional did and didn’t worry about “improving” the code. Using interfaces and Go design patterns is not improving - it’s writing proper Go imo.
> On Jan 26, 2020, at 6:14 PM, pboampo...@gmail.com wrote: > > > > === Catchable exceptions require silly contortions === > > I think the community is aware of the problem but still trying to find a more > Go-like solution. Take a look at some of the proposals if you haven't: > https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md > https://github.com/golang/go/labels/error-handling > > As you know, what we usually use now is a chain of: > x, err = f(y); if err != nil { /* handle err */ } > where *handle err* usually involves a return/goto/break, so that the nesting > level is independent of the number of steps. > > But one can also use the panic/recover mechanism locally to shorten the above > into something like this: > x, err = f(y); check(err) > Example here: https://play.golang.org/p/Gli8_bgyuDS > (Variations are possible, including error decoration and callback handlers.) > > Sometimes panic/recover across different functions (like you did) is more > appropriate. The convention is not to use it across package boundaries. > > > And all it would take to get there is two minor loosenings of restrictions. > > > > 1. The panic function has a new property, "terminating". [...] > > log.Fatal and os.Exit have the same problem. They are not "terminating > statements", so if you want them at the bottom of a function with result > parameters you have to add a panic("unreachable"). > But I think it's very rare not to have one of the "success" paths at the end; > in 8 years it happened to me like a couple of times. Do you really expect to > have throw() at the bottom of functions? > > > 2. A recover() call is no longer required to be within the lexical frame of > > a defer(). > > Would it be less ugly like this? (with recover in the catch func.) > > | defer catch("recoverable", func(err error) { > | fmt.Println("Recover:", err) > | }) > > > === Absence of iterators === > > Interesting proposal. The new expression accepted by "range" would be of type > "func() (T, bool)", called repeatedly to get the next element until false. > While the available solution is verbose and uses 2 more variables, I don't > think its readability is so bad: > > | for f := repo.commits();; { > | commit, ok := f() > | if !ok { > | break > | } > | do_stuff_to(commit) > | } > > Of course if you need the index you have to add yet more cruft. > -- > 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/d5115a08-aadb-420e-912c-9145ea7ae611%40googlegroups.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/E0B2E0BE-00CC-4447-A81E-DB2A9DE91911%40ix.netcom.com.
