question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Meta information about error context passed to _destroy and .emit('error', x)

See original GitHub issue

It would be helpful to have some meta information about the source function in which the error happened passed along with error events. Since the errors all get channeled into the one _destroy function before being emitted, it can be hard to categorize the errors programmatically as to which stage in the signaling process the error originated in. That is, unless I’m missing something.

For instance, I would like to be able to log errors categorized by the context of the failure like so:

peer.on('error', function (err) {
  var errorContext = 'createOffer'
  reportError(peer._pc, errorContext, err)
})

As it stands now, it seems difficult to discern the error context for reporting without doing something like triggering every possible error and trying to build a hardcoded index of what could come from what source. I also imagine that this approach wouldn’t be portable between browsers since some of the browser’s native error messages are passed directly through.

What I propose would be something like this using createOffer as an example:

Peer.prototype._createOffer = function () {
  var self = this
  if (self.destroyed) return

  self._pc.createOffer(function (offer) {
    if (self.destroyed) return
    offer.sdp = self.sdpTransform(offer.sdp)
    self._pc.setLocalDescription(offer, onSuccess, onError)

    function onSuccess () {
      if (self.destroyed) return
      if (self.trickle || self._iceComplete) sendOffer()
      else self.once('_iceComplete', sendOffer) // wait for candidates
    }

    function onError (err) {
      self._destroy(err, null, 'setLocalDescription') // <-- string representing failure context
    }

    function sendOffer () {
      var signal = self._pc.localDescription || offer
      self._debug('signal')
      self.emit('signal', {
        type: signal.type,
        sdp: signal.sdp
      })
    }
  }, function (err) { self._destroy(err, null, 'createOffer') }, self.offerConstraints) // <-- here again
}


Peer.prototype._destroy = function (err, onclose, errContext) { // <-- take errContext as third optional arg
  var self = this
  ...
  if (err) self.emit('error', err, errContext) // <-- pass errContext through to the error event
  self.emit('close')
}

By adding the errContext as a third optional argument to _destroy() it should keep things backwards compatible while enabling more descriptive and granular debugging and error tracking.

I’m not married to this particular solution and welcome alternative ideas on this if there is a better way.

Also I’m happy to put in the leg work and make a pull request as long as there is agreement from the maintainers that this is a welcome addition. Thanks 😃

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Comments:6 (3 by maintainers)

github_iconTop GitHub Comments

1reaction
ferosscommented, Feb 20, 2018

@RationalCoding Well, we recently changed the destroy() API, so I believe it’s just:

self.destroy(makeError(err, 'ERR_SET_LOCAL_DESCRIPTION'))
1reaction
joshonthewebcommented, Feb 20, 2018

Sounds good to me. I like this a bit better as it would avoid having to parse out function names from the stack traces. I’ll take a stab at getting some of this implemented soon.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Puppeteer Execution context was destroyed, most likely ...
Problem. The error means that you are accessing data which has become obsolete/invalid because of navigation. In your script the error ...
Read more >
iris package - github.com/azber/iris - Go Packages
var ( // ErrHandler returns na error with message: 'Passed argument is not func(*Context) neither an object which implements the iris.
Read more >
The Difference Between Node.js 10 LTS and Node.js 12 LTS
For unhandled error events with an argument that is not an Error object, the resulting exeption will have more information about the argument....
Read more >
Changelog - HTML-validate
api: allow passing object when reporting errors (f8500be) ... meta: throw schema validation error when element metadata does not validate (6ecf050), ...
Read more >
mozilla-central: changeset 488667 ...
charAt(i); + if (i === str.length) { + break; + } + } + if (buf != Number(buf) || str.charAt(i) !== "-") {...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found