Go 2 Error Handler Testing

[Liam]

I've compiled an outline of Requirements to Consider for Go 2 Error Handling.

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.

Note, these examples assume named handlers and other requirements that place the handler body after its invocations. They're analogous to:

func f(i int) {
   handle hname { ... }
   check x(i)
}

[Burak Serdar]

On Tue, Oct 30, 2018 at 2:15 PM Liam <networ...@gmail.com> wrote:
>
> I've compiled an outline of Requirements to Consider for Go 2 Error Handling.
>
> 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.

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.

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?

>
> Note, these examples assume named handlers and other requirements that place the handler body after its invocations. They're analogous to:
>
> func f(i int) {
> handle hname { ... }
> check x(i)
> }
>
>

> --
> 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.
> For more options, visit https://groups.google.com/d/optout.

[Liam Breck]

On Tue, Oct 30, 2018, 4:08 PM Burak Serdar <bse...@ieee.org> wrote:

On Tue, Oct 30, 2018 at 2:15 PM Liam <networ...@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!