doc: add error documentation #789
Conversation
| opportunity to **intercept** this error based on how the API **propagates** it. | ||
|
|
||
| The style of API called determines how generated errors are handed back, or | ||
| **propagated**, to client code, which in turn informs how client may **intercept** |
There was a problem hiding this comment.
"how clients" or "how the client"
|
@chrisdickinson amazing amount of information here. Thanks for the docs. I would like another set of eyes on it, but overall LGTM. |
|
|
||
| <!--type=misc--> | ||
|
|
||
| Errors generated by Node.js fall into two categories: JavaScript errors and system |
There was a problem hiding this comment.
Node -> io.js ?
other api docs were updated in #750
There was a problem hiding this comment.
Changed most of these references. Retained "node style callback," since it seems disingenuous for io.js to claim credit for that pattern :)
|
|
||
| Instantiates a new Error object and sets its `.message` property to the provided | ||
| message. Its `.stack` will represent the point in the program at which `new Error` | ||
| was called. Stack traces are subject to [V8's stack trace API](https://code.google.com/p/v8/wiki/JavaScriptStackTraceApi). |
There was a problem hiding this comment.
If I follow this link, it says that the page has moved to https://code.google.com/p/v8-wiki/wiki/JavaScriptStackTraceApi
There was a problem hiding this comment.
Fixed. Thanks!
|
Thanks @trevnorris. @geek care to take a look? |
|
|
||
| #### ETIMEDOUT: Operation timed out | ||
|
|
||
| An connect or send request failed because the connected party did not properly |
|
LGTM, this is super useful! |
| The style of API called determines how generated errors are handed back, or | ||
| **propagated**, to client code, which in turn informs how client may **intercept** | ||
| the error. Exceptions can be intercepted using the `try / catch` construct; | ||
| other propagation strategies are covered [below](#errors_error_propagation_and_interception). |
There was a problem hiding this comment.
I'm not sure if this is linking properly?
There was a problem hiding this comment.
This appears to be working locally for me.
|
cc @rvagg – want to take a look and see if this is good to go for v1.2.0? |
|
@chrisdickinson only a quick scan but this looks good to me, we can iterate post-merge to improve if needed IMO. Get it in quick cause I've got the release commit on my computer ready to push. |
|
Cool. Merging now. |
PR-URL: #789 Reviewed-by: Rod Vagg <rod@vagg.org> Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
|
Merged in 7e2235a |
| restrictions, a **system error** is generated. Client code is then given the | ||
| opportunity to **intercept** this error based on how the API **propagates** it. | ||
|
|
||
| The style of API called determines how generated errors are handed back, or |
There was a problem hiding this comment.
This first line should be obvious to readers, I don't think it needs to be said.
|
@chrisdickinson Do I misread, or was this 5 hours from PR to merge? That's too short to get feedback, I think. |
|
@chrisdickinson I added a couple of points of feedback. Amazing job, this should appeal to all developer levels. |
|
@sam-github I think it was worth it to get it out and live for 1.2.0 (Also, it's docs. easy to change.) |
|
@geek Mind PR-ing those? |
|
@Fishrock123 @sam-github It already went through a round of review here. So, five hours plus five months :) I did want to get this out with 1.2.0, hence the accelerated review + merge in the io.js case. @geek thanks for the review! |
This adds error documentation, covering "JS errors" and "system errors." It is roughly a continuation of this PR, with some remaining comments cleaned up.
R=@trevnorris