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!
So the main point of the try…catch in this exercise, is to demonstrate that by catching the error, you are still able to continue running your code to the end?
That’s correct. Instead of letting the interpreter handle the error, we do that in our code and flow is unbroken.
let u;
let e = "";
do {
u = prompt(e + "Enter a number between 0 and 100");
try {
if (u > 0 && u < 100) {
u = +u;
break;
}
if (u === null) {
break;
}
throw 'anException';
}
catch(error) {
e = "Try again... "
}
} while (true);
There are no real exceptions in this code so we have to throw one. Since JS is loosely typed, number operations either result in a number, or NaN and JS churns along either way.
When using prompt() we need to test for null to see if the Cancel button was clicked or the Esc key pressed.
There are of course many ways to approach this problem with exception handling. This is by no means a conclusive example.
i have different types of errors, e.g. syntax error, reference error but my catch function never worked for these errors. but only for the one that’s given in the exercise…
i didnt understand, if try… catch doesnt work for all kinds of errors, then what’s the point?
Syntax errors are found during parsing. They are not run-time errors. Try-catch is for working around possible run-time errors such as mismatched types, reference errors, division by zero, and so on.
so what do we do with our error or what advantage does try and catching the error offer more than the normal built in error function which will easily give the error. ofr built in error type?
If the error is predictable, meaning we might expect it then catching the error lets us handle how it is addressed without throwing a fatal error. This allows the program to continue and the user can be prompted for new input for another go around.
When the error is unforeseen, meaning it is likely a bug in the code, then we would be better off to let the interpreter/compiler catch it and throw a fatal error from which we can garner details of the cause and where it was caught. We can use that information to go into the code and locate/correct the bug.
This speaks to extensive testing before releasing code to the production world. We need to catch all the unforeseen errors and fix them so that the only possible errors are the user caused ones as described earlier.
I don’t really get the point of the try…catch statement. Like the error is still an error either way, what difference does it make if it’s from the console or if I make it. If anyone can explain thank you!.
In the documentation, have a look at exception_var where it is mentioned that this is an optional identifier which can be omitted if the exception’s value is not used in the catch block.
Add a catch statement after the try block and inside the catch block log the error to the console.
The console.log statement in your catch block informs us that an error was caught but doesn’t reveal anything as to the nature of the error. I think the intent of the phrase “log the error to the console” is to log a more informative error message.
Why is letting our program run after encountering an error desirable? The example given was a data mismatch, but since we probably need to do something to that data then return something, why would we want our code to keep going after it doesn’t have it’s appropriate information to work with?
The only explanation that sort of makes sense is @mtf 's explanation about allowing the user to provide new input, but if the error is predictable, why wouldn’t we handle that before it throws an error through regex patterns for user input or some other means?
Why would we allow a predictable error to occur at all? By definition shouldn’t we predict and then fix it?
Some things cannot be fixed and may only throw an exception in rare instances. Writing code to handle those instances may only complicate the code, leave room for more bugs, and possibly not fix all the edge cases anyway. Error handling lets us write less code, and handle any errors that crop up (usually around user inputs, but also even possibly caused by the program) without crashing the program. It lets us identify the type of error, and write different actions for each type of error.
We don’t want code that is full of bugs, which is where exceptions come in to alert us during the build and test phase. Once the program is out in the wild we don’t want it to be crashing for our user, but rather direct traffic around the error.
As for regex, that is a tricky business unless one is totally up to snuff in writing patterns. It is a tall order for most of us.
Because we want the function to validate and handle any exception (error) internally, and in the enclosed scope of the function, not in global scope. That would mean testing before calling the function, which is counterintuitive, at the very least.
Aside
As our program grows in complexity we need to be mindful of which statement(s) could or might throw an error and head off only that(those) statement(s) in a try clause, and leave the rest of the code outside of that.
) below.
) to up-vote the contribution!