`log.Trigger()` buries panics about go-sdk

[dhermes]

This is where the listener goroutine gets triggered:

go-sdk/logger/logger.go

Line 125 in 5bb3dbe

go eventListener.Start()

I was hoping the explanation was just that a panic in a goroutine doesn't cause the main goroutine to fail but https://play.golang.org/p/5gkWQhNI-F7 put that hunch to rest.

[dhermes]

OK I see the recover():

go-sdk/logger/worker.go

Lines 130 to 135 in 5bb3dbe

	defer func() {
	if r := recover(); r != nil {
	err = ex.New(r)
	return
	}
	}()

and then the place where the recovered panic gets put in an error channel owned by the worker:

go-sdk/logger/worker.go

Lines 121 to 123 in 5bb3dbe

	if err = w.Process(e); err != nil && w.Errors != nil {
	w.Errors <- err
	}

---

However, when log.Listen() is invoked, it calls NewWorker:

go-sdk/logger/logger.go

Line 123 in 5bb3dbe

eventListener := NewWorker(listener)

and NewWorker leaves the Worker.Errors channel as nil:

go-sdk/logger/worker.go

Lines 11 to 17 in 5bb3dbe

	func NewWorker(listener Listener) *Worker {
	return &Worker{
	Latch: async.NewLatch(),
	Listener: listener,
	Work: make(chan EventWithContext, DefaultWorkerQueueDepth),
	}
	}

so these errors just end up getting swallowed.

---

This "problem" is not so easy to solve since using a buffered channel, e.g.

	return &Worker{
		Latch:    async.NewLatch(),
		Listener: listener,
		Work:     make(chan EventWithContext, DefaultWorkerQueueDepth),
		Errors:   make(chan error, 100),
	}

would eventually fill up and block the listener fully (until some other code started consuming the Errors channel).