On Tue, Oct 30, 2018, 4:08 PM Burak Serdar <bser...@ieee.org> wrote: > On Tue, Oct 30, 2018 at 2:15 PM Liam <networkimp...@gmail.com> wrote: > > > > I've compiled an outline of Requirements to Consider for Go 2 Error > Handling.
> https://gist.github.com/networkimprov/961c9caa2631ad3b95413f7d44a2c98a > > > > Recently I was asked about support for a test harness in functions that > contain error handlers; my document doesn't address this. My first guess is > that the tooling could generate a function to mirror the one being tested, > which takes a slice argument with a handler input (or function to call) for > each handler invocation site in the function: > > > > func f(i int) { // function to test > > op hname = x(i) > > handle hname T { ... } > > } > > func f_errors(i int, e [1]interface{}) { // generated for go-test > > op hname = e[0].(T) // or e[0].(func(int)T)(i) > > handle hname T { ... } > > } > > > > > > I'd love to hear other ideas about triggering error handlers from a test > harness. > > You don't need the new handler syntax to do this, although the 'check' > keyword would make things much easier. You can parse a function, > identify all error returning calls, and replace them with a call to a > func() passed in as an argument. > Parse & replace, yes above I suggested the compiler could do that in a testing pass, generating f_errors() But something like this would be very hard to maintain, I think. When > you reorganize the function, you need to reorder that []interface > argument to match. > Need to reorder the argument, yes but that only adds burden for functions whose effect is unchanged by reordering. I once did something like this, in a Java project, by manually > instrumenting the code to put named breakpoints, so I can intercept > the execution. I think in something like this the key is to be able to > invoke handlers by name, not by sequence. So if you already rewrote > the function, why not pass in a map[string]func(), keyed by handler > name? > f_errors(..., e map[string]interface{}) is a useful alternative. The compiler could generate that or f_errors(..., e []interface{}), depending on the type passed by the caller. Thanks for the feedback! -- 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.
