There are currently no frequently asked questions associated with this exercise – that’s where you come in! You can contribute to this section by offering your own questions, answers, or clarifications on this exercise. Ask or answer a question by clicking reply () below.
If you’ve had an “aha” moment about the concepts, formatting, syntax, or anything else with this exercise, consider sharing those insights! Teaching others and answering their questions is one of the best ways to learn and stay sharp.
Join the Discussion. Help a fellow learner on their journey.
Ask or answer a question about this exercise by clicking reply () below!
Agree with a comment or answer? Like () to up-vote the contribution!
Yes. This is a deliberate mistake which I made in order to check the try…catch construction. This construction worked when I “forgot” quotes around the cat’s name, but in the case of semicolon it doesn’t. I don’t understand why it is so.
I fell in the same trap. Nowhere in the explanation does it say that try…catch can only be used with runtime errors. Perhaps this can be added to the explanation or posted as a forum question at the end of the lesson in the Community Forums section?
Same, none of the simple errors I was putting in were being caught because they were all syntax errors. Even just trivial stuff like declaring the same variable twice. Was very confused.
Simple answer: Before the program can even be run. It won’t run as long as they persist. Where are we going to try and catch anything at this stage if our code won’t run?
A try and catch is more like a switch that we use to filter potentially bad data through. All the code that runs without errors is not included in this picture. Just the suspect code.
Operative word, ‘data’. We wouldn’t be seeing any of it if the code were not running; ergo, throwing a runtime error. We use try and catch to divert them so they are not fatal errors. It’s the author’s responsibility to foresee the potential for fatal errors and write subroutines for those events. That is where try and catch are our tools.
Bottom line, get to know your error codes, and all the Error class, inside and out. This is scalpel, not sword. Watch only what needs to be watched. That is to say, one should exhaust all other means of error checking before resorting to this avenue of intervention. We should intervene first, and failing that… But, there is reasonable and logical reason to use this mechanism up front in many cases so it should not be deemed a last resort. Sometimes it is the intervention that is best suited. Just saying.
We’re going to be intervening the most on user input, not our own code. Moot point, when we think about it. It is user input that is always coming into question. We don’t trust user input, period. So we put it to the test…
try {
console.log(userInput.length) // a number has no length property
}
only userInput is likely a string, at this point, not a number. So it does.
Makes sense! Just not something I intuited on this pass at things(even as a somewhat experienced coder and bootcamp grad doing this course for revision and deeper depth). They’d be wise to include an explanation like yours in future versions of this lesson.
Now that I learn Error handling concept in javascript, especially throwing custom error with ‘throw’ keyword, I’m curious how html form validation works internally. You know, html form throws error message too when user’s input doesn’t feet to the requirement of form.
Is html form validation concept built on some try and catch error handling system, too?
Bear in mind that HTML5 brought in a number of field constraint options that were not there when forms were originally thought out. For our purposes, we are best to think in pre-HTML5 terms, just for some relative bearing. Forms have been around for a very long time and their core definitions bear some learning. This is science, and I’m glad to see you treat it as such.
) below.
) to up-vote the contribution!
seems not to be caught, since I receive the message:
Just not something I intuited on this pass at things(even as a somewhat experienced coder and bootcamp grad doing this course for revision and deeper depth). They’d be wise to include an explanation like yours in future versions of this lesson.
