Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refac(net, exchange, dht) network service errors #101

Closed
wants to merge 2 commits into from

Conversation

btc
Copy link
Contributor

@btc btc commented Sep 22, 2014

Let errors rise up up and away.

@jbenet @whyrusleeping

@btc btc added the status/in-progress In progress label Sep 22, 2014
@btc btc added codereview and removed status/in-progress In progress labels Sep 22, 2014
@btc btc self-assigned this Sep 23, 2014
Brian Tiger Chow added 2 commits September 24, 2014 19:56
Rather than pushing errors back down to lower layers, propagate the
errors upward.

This commit adds a `ReceiveError` method to BitSwap's network receiver.

Still TODO: rm the error return value from:

    net.service.handler.HandleMessage

This is inspired by delegation patterns in found in the wild.
@btc btc force-pushed the feat/network-error-propagation-1 branch from d4036d0 to 623cb6c Compare September 24, 2014 23:57
@btc
Copy link
Contributor Author

btc commented Sep 24, 2014

Let me know if anything is needed before the merge.

@whyrusleeping
Copy link
Member

Rise! Rise! RISE!!! (errors, that is)

@btc
Copy link
Contributor Author

btc commented Sep 25, 2014

Now we're cooking with gas. Merged locally

@btc btc closed this Sep 25, 2014
@btc btc removed the codereview label Sep 25, 2014
@btc btc deleted the feat/network-error-propagation-1 branch September 25, 2014 03:37
@whyrusleeping
Copy link
Member

by "merged locally" do you mean you merged it to master on your computer, then pushed?

@@ -20,7 +20,7 @@ type Handler interface {

// HandleMessage receives an incoming message, and potentially returns
// a response message to send back.
HandleMessage(context.Context, msg.NetMessage) (msg.NetMessage, error)
HandleMessage(context.Context, msg.NetMessage) msg.NetMessage
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

curious: why couldnt the same error propagation work, and then have Service be the only one to send it over to through a channel?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

e.g.

func (w *whatever) HandleMessage(context.Context, msg.NetMessage) (msg.NetMessage, error) {
  // do whatever
  return nil, errors.New("beep boop")
}

// in service.go
func (s *Service) handleIncomingMessage(ctx context.Context, m msg.NetMessage) {

  ...

  r1, err := s.Handler.HandleMessage(ctx, m2)
    if err != nil {
        go something.ReceiveError(err)
        return
    }

  ...
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes are based on this discussion:

#69 (comment)

It's that it's weird to send errors back down to the service. What does it mean to return error in a handler function? What is the service meant to do with this error?

It would appear that the better thing to do is for the handler to log and perform error handling internally.

@jbenet
Copy link
Member

jbenet commented Sep 25, 2014

I'm late to the party but am worried that this -- which removes error from lots of function signatures, hides away the details of how errors are sent.

Maybe not, maybe it's apparent because you have to spin out goroutines which have to report errors the same way... idk. makes me uneasy cause now i can't look at a function signature and know clearly exactly how it fails.

@btc
Copy link
Contributor Author

btc commented Sep 25, 2014

Recall #69 (comment)

@jbenet
Copy link
Member

jbenet commented Sep 25, 2014

idk what's right. :/ yeah i recall now-- thanks for link. Looking at this code makes me uneasy though. So the tension is between:

Writing functions with clear failure semantics.

and

Knowing where the errors are being reported to.

both are important to know, but what's more important to interactions with the codebase going fwd?

@btc
Copy link
Contributor Author

btc commented Sep 25, 2014

When receiving a raw ethernet packet, what does it mean to return an error to the device driver? Here, what does it mean to return an error to the network layer?

@btc
Copy link
Contributor Author

btc commented Sep 25, 2014

Having error handling performed by the network layer does reduce code duplication though. Error handling is performed just once.

@btc btc removed their assignment Mar 30, 2015
@aschmahmann aschmahmann mentioned this pull request Feb 18, 2021
73 tasks
ribasushi pushed a commit that referenced this pull request Jul 4, 2021
Add an option to pass URL to zap
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants