Find a way to fix panicing goroutine test

[cyberhck]

That assert is commented out.
Background: right now, that's commented out because it panics inside a go routine and Assert.Panics can't capture that. Figure out what to do with this.

https://github.com/cyberhck/go-captain/blob/a8e1216ac7187ae5af42b88c5e645b9d00b7885b/job_test.go#L162-L171

[matryer]

Panics are hard. Have you considered an alternative way of handling errors? I don’t think an ‘error’ type should end up as a panic, because returning errors is ok and should be part of normal

[matryer]

... flow. Panics are messages to developers.

[cyberhck]

Thanks for immediate response.

hmm. I don't know what I should do in this context, do you have any suggestions as to what to do on this condition? Idea is if runtime processor returns an error we should abort, or something.

Or do you think runtime shouldn't really return anything, they're just kind of hooks, do you think we want to return anything at all?

[matryer]

I always prefer simpler. So yeah, don’t return anything like HTTP handlers and let them manage their own errors?

…

On 29 Jan 2018, at 08:26, Nishchal Gautam ***@***.***> wrote: Thanks for immediate response. hmm. I don't know what I should do in this context, do you have any suggestions as to what to do on this condition? Idea is if runtime processor returns an error we should abort, or something. Or do you think runtime shouldn't really return anything, they're just kind of hooks, do you think we want to return anything at all? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[cyberhck]

closing this, I'm gonna remove the ability to return an error so we can use the Adapter pattern too :)