[lucy-dev] Go bindings -- error handling

[Marvin Humphrey <ma...@rectangular.com>]

On Mon, Nov 17, 2014 at 1:12 PM, Marvin Humphrey <ma...@rectangular.com> wrote:

> *   Clownfish exception handling has been implemented using Go's
>     panic/recover/defer.

A THROW in Clownfish C code triggers a Go `panic`.  The argument to `panic` is
the Err object, which implements the Go `error` interface.

This makes it possible to trap an error in a Clownfish C code from Go-space,
using Go's `recover`.

Unfortunately some Clownfish exceptions will still leak memory.  (Too bad C
doesn't have Go's `defer` facility!)

> *   Idiomatic Go error handling is achieved by trapping exceptions in
>     user-level method wrappers and returning an `error` alongside any return
>     value.

In keeping with Go traditions, we report errors using a multi-valued return
and avoid throwing exceptions that the user would be expected to catch.  This
means that autogenerated top-level method bindings will have to trap
exceptions.

    hits, err := searcher.Hits(query, 0, 10, nil)
    if err != nil {
        log.Fatal(err) // or return nil, whatever.
    }

(It might be easier to achieve such functionality if Clownfish methods
declared their "throws" -- then CFC would know which exceptions to trap and
which to let through.)

Marvin Humphrey

Re: [lucy-dev] Go bindings -- error handling

[Nick Wellnhofer <we...@aevum.de>]

On 01/12/2014 09:12, Marvin Humphrey wrote:
> On Mon, Nov 17, 2014 at 1:12 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
>
>> *   Clownfish exception handling has been implemented using Go's
>>      panic/recover/defer.
>
> A THROW in Clownfish C code triggers a Go `panic`.  The argument to `panic` is
> the Err object, which implements the Go `error` interface.
>
> This makes it possible to trap an error in a Clownfish C code from Go-space,
> using Go's `recover`.
>
> Unfortunately some Clownfish exceptions will still leak memory.  (Too bad C
> doesn't have Go's `defer` facility!)
>
>> *   Idiomatic Go error handling is achieved by trapping exceptions in
>>      user-level method wrappers and returning an `error` alongside any return
>>      value.
>
> In keeping with Go traditions, we report errors using a multi-valued return
> and avoid throwing exceptions that the user would be expected to catch.  This
> means that autogenerated top-level method bindings will have to trap
> exceptions.
>
>      hits, err := searcher.Hits(query, 0, 10, nil)
>      if err != nil {
>          log.Fatal(err) // or return nil, whatever.
>      }
>
> (It might be easier to achieve such functionality if Clownfish methods
> declared their "throws" -- then CFC would know which exceptions to trap and
> which to let through.)

Looks very nice!

Nick