Good to see nice consistent code layout :) Makes it easier to digest code when it feels familiar.
Eating exceptions like this is not a good idea, you never know if it was failure in the reading or something else.
Not sure the best solution for this bit, could even generate a note with the failure info?
It is the sort of thing that comes back later to bite you.
hth
Woz
try {
var notesString = fs.readFileSync('notes-data.json')
notes = JSON.parse(notesString)
} catch (e) {
}
I see what you are saying with this and I thought about it when going through this exercise. This section in the course left the code like this, but it makes sense to give some feedback if an error occurred. I think the next section will be refactoring this bit of code so that the logic can be reused by other functions. We'll see when I get there.
Will be interesting to see what they propose is the correct way after the refactor :)
One other thing I noticed is there is no try/catch around the writing of the file so if that fails for whatever reason it will bubble up while the read is caught. Was that intentional?
I agree with this. Maybe you can try making it fail on purpose (trying to open a file that doesn't exist for example) and then
console.log(e)so you can see what is returned. Normally when I catch errors I doconsole.log(e.stack), and it gives enough explanation of what happened.Also, I learned how to use
.filter()with your post and the further explanation that @kkomaz wrote.