API return values... net.service.handler.HandleMessage

[btc]

Continuing discussion from #69 (comment)

@perfmode good point, that doesn't make much sense. See https://github.com/jbenet/go-ipfs/blob/net/net/service/service.go#L183-L188 Think it should just return a message, and handle/log/whatever its own error?

Yeah.

If something goes wrong when handling a message, trttd might be to propagate the error upward. ie. an error channel or an error recorder (à la vitess) used by the service (DHT, BitSwap)

[jbenet]

oh nice find!!

if only ... you know ... we could just import those types........! grrr. soon.

[btc]

some initial work in #101

TODO decide on an error logging strategy and start passing errors up to the IPFS Core.

[whyrusleeping]

So, what about the core having a master context with an error channel for all child contexts to report errors through. This way when the core 'Starts' it can start reading on the channel, and that way will never cause any deadlocks or loss of data in its children who are sending errors up through the channel

[btc]

+1

On Mon, Sep 22, 2014 at 4:41 PM, Jeromy Johnson [email protected]
wrote:

So, what about the core having a master context with an error channel for all child contexts to report errors through. This way when the core 'Starts' it can start reading on the channel, and that way will never cause any deadlocks or loss of data in its children who are sending errors up through the channel

Reply to this email directly or view it on GitHub:
#98 (comment)

[jbenet]

+1 —
Sent from Mailbox

On Mon, Sep 22, 2014 at 1:55 PM, Brian Tiger Chow
[email protected] wrote:

+1
On Mon, Sep 22, 2014 at 4:41 PM, Jeromy Johnson [email protected]
wrote:

So, what about the core having a master context with an error channel for all child contexts to report errors through. This way when the core 'Starts' it can start reading on the channel, and that way will never cause any deadlocks or loss of data in its children who are sending errors up through the channel

Reply to this email directly or view it on GitHub:

#98 (comment)

Reply to this email directly or view it on GitHub:
#98 (comment)

[btc]

Here's a radically unintrusive approach:

https://gist.github.com/perfmode/f2951c1ed3a02c484d0b#file-context_test-go

[jbenet]

<3 https://gist.github.com/perfmode/f2951c1ed3a02c484d0b#comment-1304444

On Mon, Sep 22, 2014 at 2:56 PM, Brian Tiger Chow [email protected]
wrote:

Here's a radically unintrusive approach:

https://gist.github.com/perfmode/f2951c1ed3a02c484d0b#file-context_test-go

—
Reply to this email directly or view it on GitHub
#98 (comment).

[whyrusleeping]

closing, no longer relevant