Hello documentation? about node-oauth

[ciaranj]

Um, say-what ? There is a single commit (3c45927) that isn't in the published npm package (0.9.5) [and it has nothing to do with the constructor] Have you tried the wiki which has examples in it ?

[demian85]

oauth.js is totally different after an npm installation. I cloned it with git and now it works.

[ciaranj]

I've re-tested this morning 'npm install oauth' installs exactly the same version of the library as the 0.9.5 tag in the repository.. I'm utterly at a loss as to how you experienced this issue?

[demian85]

oauth or node-oauth?? which is the package name?? i installed node-oauth

[ciaranj]

'oauth' presumably someone has added a new library of 'node-oauth' which goes against the npm naming standards :( how nice of them ;)

[demian85]

Sorry but i don't know where to ask for basic things...
Can you explain which type of error the method get() receives as the first argument? it seems i'm getting a different one every time. Sometimes i get an Error instance and sometimes i get a custom object with "statusCode" and stuff.
Could you please follow node standards and send en Error instance as the first parameter?? I would like to log "err.message"...

[ciaranj]

FWIW I'm unaware of any such node 'standard', I'm interested in the details if you can point me at it? In any case, yes these are the 2 types of 'error' you will receive.

In the case of a node/stream/connection level error you will receive node's underlying (Javascript) Error object that you can log.

The OTHER error case is not an error in the node sense, but an error in the OAuth sense, in this case you will receive an object literal that consists of the 2 parts; 'statusCode' and 'data' where 'statusCode' is the HTTP status received from the server (likely a 4xx or 5xx) and 'data' is the response stream that had been received, if any.

[demian85]

And how am I supposed to know which is the case?
Don't you think that sending always an Error instance makes more sense?
Take a look around, 99% of node modules handle callback errors that way.

[ciaranj]

If ( error && error.statusCode) {
// Oauth issue
}
else if (error) {
// node problem
}

[demian85]

Omg you are a genius, that must be the most optimum solution ever. Why
nobody does it like that? Oh wait, maybe because what I told you is the best
solution?
El 05/09/2011 03:03, "ciaranj" <
[email protected]>
escribi:

If ( error && error.statusCode) {
// Oauth issue
}
else if (error) {
// node problem
}

On Monday, September 5, 2011, demian85 <
[email protected]>
wrote:

And how am I supposed to know which is the case?
Don't you think that sending always an Error instance makes more sense?
Take a look around, 99% of node modules handle callback errors that way.

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

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

[ciaranj]

Ok, so lets say that we decide that an error object is returned, how do you propose distinguishing between the two types of error case in this situation?

(Given I accept fully that error handling in node is generally a bit klunky, passing an error as the first argument will never be the optimum case)

[demian85]

var e = new Error("everything is broken!");
e.statusCode = 404;
e.someShit = "asdf"
callback(e);

That way i can always log e.message
El 05/09/2011 08:38, "ciaranj" <
[email protected]>
escribi:

Ok, so lets say that we decide that an error object is returned, how do
you propose distinguishing between the two types of error case in this
situation?

(Given I accept fully that error handling in node is generally a bit
klunky, passing an error as the first argument will never be the optimum
case)

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

[ciaranj]

I get that your requirement is that you can always 'log message' and using an error object would give you that (also adding a message property to the passed back object literal would do this too, always happy to accept patches)

My question however was given your assertion with regards to my suggestion for dealing with the extreme and burdenous complexity of dealing with two different 'types' coming back in the error callback how would you deal with it differently, as far as I can tell you'd need the exact same code (which apparently is the least optimum solution?)

Also, as with all my libraries ...which I write for my own purposes and share in case they're useful to others.... node-oauth is MIT licensed so you're welcome to fork it and make it so the error comes back in a form you're more comfortable dealing with.

I cannot (will not) change the returned error object to be an 'Error' as that will quite likely break any existing code out there that depends on the type inference to act appropriately. But as stated above if you want to submit a pull request for adding a message property to the returned object so your logging code only uses a single if-null guard, rather than if-null-and-message guard then I'm more than happy to accept it :)