Does the HTTP Response Stream need error event handlers In Node.js?
I tried many experiments but I could not get HTTP OutgoingMessage to fire error event ever. But I know OutgoingMessage is basically a WritableStream and as such prone to error.
Also, when I read this official Node.js docs about Anatomy of an HTTP transaction, it is recommended to handle errors on the Response Stream.
If yes, what scenarios will cause error event to fire up? Should I just swallow these errors silently?
javascript node.js marblejs
add a comment |
I tried many experiments but I could not get HTTP OutgoingMessage to fire error event ever. But I know OutgoingMessage is basically a WritableStream and as such prone to error.
Also, when I read this official Node.js docs about Anatomy of an HTTP transaction, it is recommended to handle errors on the Response Stream.
If yes, what scenarios will cause error event to fire up? Should I just swallow these errors silently?
javascript node.js marblejs
add a comment |
I tried many experiments but I could not get HTTP OutgoingMessage to fire error event ever. But I know OutgoingMessage is basically a WritableStream and as such prone to error.
Also, when I read this official Node.js docs about Anatomy of an HTTP transaction, it is recommended to handle errors on the Response Stream.
If yes, what scenarios will cause error event to fire up? Should I just swallow these errors silently?
javascript node.js marblejs
I tried many experiments but I could not get HTTP OutgoingMessage to fire error event ever. But I know OutgoingMessage is basically a WritableStream and as such prone to error.
Also, when I read this official Node.js docs about Anatomy of an HTTP transaction, it is recommended to handle errors on the Response Stream.
If yes, what scenarios will cause error event to fire up? Should I just swallow these errors silently?
javascript node.js marblejs
javascript node.js marblejs
edited Nov 26 '18 at 16:06
Harshal Patil
asked Nov 24 '18 at 7:04
Harshal PatilHarshal Patil
2,41711140
2,41711140
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Handling error is not required for streams or anything in NodeJS, but is good practice. There is even a concept: error-first callbacks in NodeJS and the first parameter in a callback is actually an error object.
Lets imagine case where you don't handle and error:
fs.readFile('./non_existing_file.json', (err, data) => {
// here we don't handle the error
// and if there is an error
// the second parameter will be undefined
let myDataObj = JSON.parse(data)
...more code...
})
Now we did not handled the the error and when trying to parse undefined we get an error which crashes our application. We need to manually start our application.
By handling the error:
fs.readFile('./some_file.json', (err, data) => {
if(err) throw err
// if there is an error
// the rest of the function won't be executed
let myDataObj = JSON.parse(data)
...more code...
})
Now this will log an error telling us what exactly went wrong and our application won't crash, it will just log the error.
It is not necessary to log the error, we just log it to help us debugging. Of course you can safely swallow it by replacing if(err) throw err with if(err) return
It is up to you to decide how to handle errors or to handle them at all. It is good thing to log them and even better to notify your users that something went wrong.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53455973%2fdoes-the-http-response-stream-need-error-event-handlers-in-node-js%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Handling error is not required for streams or anything in NodeJS, but is good practice. There is even a concept: error-first callbacks in NodeJS and the first parameter in a callback is actually an error object.
Lets imagine case where you don't handle and error:
fs.readFile('./non_existing_file.json', (err, data) => {
// here we don't handle the error
// and if there is an error
// the second parameter will be undefined
let myDataObj = JSON.parse(data)
...more code...
})
Now we did not handled the the error and when trying to parse undefined we get an error which crashes our application. We need to manually start our application.
By handling the error:
fs.readFile('./some_file.json', (err, data) => {
if(err) throw err
// if there is an error
// the rest of the function won't be executed
let myDataObj = JSON.parse(data)
...more code...
})
Now this will log an error telling us what exactly went wrong and our application won't crash, it will just log the error.
It is not necessary to log the error, we just log it to help us debugging. Of course you can safely swallow it by replacing if(err) throw err with if(err) return
It is up to you to decide how to handle errors or to handle them at all. It is good thing to log them and even better to notify your users that something went wrong.
add a comment |
Handling error is not required for streams or anything in NodeJS, but is good practice. There is even a concept: error-first callbacks in NodeJS and the first parameter in a callback is actually an error object.
Lets imagine case where you don't handle and error:
fs.readFile('./non_existing_file.json', (err, data) => {
// here we don't handle the error
// and if there is an error
// the second parameter will be undefined
let myDataObj = JSON.parse(data)
...more code...
})
Now we did not handled the the error and when trying to parse undefined we get an error which crashes our application. We need to manually start our application.
By handling the error:
fs.readFile('./some_file.json', (err, data) => {
if(err) throw err
// if there is an error
// the rest of the function won't be executed
let myDataObj = JSON.parse(data)
...more code...
})
Now this will log an error telling us what exactly went wrong and our application won't crash, it will just log the error.
It is not necessary to log the error, we just log it to help us debugging. Of course you can safely swallow it by replacing if(err) throw err with if(err) return
It is up to you to decide how to handle errors or to handle them at all. It is good thing to log them and even better to notify your users that something went wrong.
add a comment |
Handling error is not required for streams or anything in NodeJS, but is good practice. There is even a concept: error-first callbacks in NodeJS and the first parameter in a callback is actually an error object.
Lets imagine case where you don't handle and error:
fs.readFile('./non_existing_file.json', (err, data) => {
// here we don't handle the error
// and if there is an error
// the second parameter will be undefined
let myDataObj = JSON.parse(data)
...more code...
})
Now we did not handled the the error and when trying to parse undefined we get an error which crashes our application. We need to manually start our application.
By handling the error:
fs.readFile('./some_file.json', (err, data) => {
if(err) throw err
// if there is an error
// the rest of the function won't be executed
let myDataObj = JSON.parse(data)
...more code...
})
Now this will log an error telling us what exactly went wrong and our application won't crash, it will just log the error.
It is not necessary to log the error, we just log it to help us debugging. Of course you can safely swallow it by replacing if(err) throw err with if(err) return
It is up to you to decide how to handle errors or to handle them at all. It is good thing to log them and even better to notify your users that something went wrong.
Handling error is not required for streams or anything in NodeJS, but is good practice. There is even a concept: error-first callbacks in NodeJS and the first parameter in a callback is actually an error object.
Lets imagine case where you don't handle and error:
fs.readFile('./non_existing_file.json', (err, data) => {
// here we don't handle the error
// and if there is an error
// the second parameter will be undefined
let myDataObj = JSON.parse(data)
...more code...
})
Now we did not handled the the error and when trying to parse undefined we get an error which crashes our application. We need to manually start our application.
By handling the error:
fs.readFile('./some_file.json', (err, data) => {
if(err) throw err
// if there is an error
// the rest of the function won't be executed
let myDataObj = JSON.parse(data)
...more code...
})
Now this will log an error telling us what exactly went wrong and our application won't crash, it will just log the error.
It is not necessary to log the error, we just log it to help us debugging. Of course you can safely swallow it by replacing if(err) throw err with if(err) return
It is up to you to decide how to handle errors or to handle them at all. It is good thing to log them and even better to notify your users that something went wrong.
answered Nov 24 '18 at 9:01
Nedko DimitrovNedko Dimitrov
428515
428515
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53455973%2fdoes-the-http-response-stream-need-error-event-handlers-in-node-js%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown