Notes on Week 5 (Chapter 10)

Errors, Exceptions, and Warnings
System error ― there’s a problem with the system or external devices with which the program is interacting.
Programmer error ― the program contains incorrect syntax or faulty logic; it could even be as simple as a typo.
User error ― the user has entered data incorrectly, which the program is unable to handle.

Exception
exception is an error that produces a return value that can then be used by the program to deal with the error
Stack Trace can be very helpful - you can follow the listing to trace where the problem lies
Warnings - warning can occur if there’s an error in the code that isn't enough to cause the program to crash
-- this can be a problem if the program runs incorrectly but still runs
Because it is loosely typed some errors can slip through the code, you can enforce a strict mode -> 'use strict';
-- this will make it throw an exception instead of a warning (if the engine will accept the mode)
In can be used in a function or a strict function that will run the whole program code.

---

Linting Tools
options to use linting tools help when enforcing a style guide, it will help catch errors live but won't necessarily guarantee anything.
ESLint inthis article on SitePoint - https://www.sitepoint.com/up-and-running-with-eslint-the-pluggable-javascript-linter/.
Feature detectors are best implemented in an if statement - therefore only running if it is capable.
if (window.holoDeck) {
virtualReality.activate();
}

---

Debugging in the browser is my favorite way of checking how things work, and when they are implemented, even why they don't.
The book says the 'trusty alert is the basic form of debugging' however, I like console.log(); and debugger;
function amIOldEnough(age){
if (age = 12) {
alert(age);
return 'No, sorry.';
} else if (age < 18) {
return 'Only if you are accompanied by an adult.';
}
else {
return 'Yep, come on in!';
}
}
the above code has a bug... should check for under 12 not assigned variable to 12
console.trace() method will log an interactive stack trace in the console
breakpoints that allow pausing and ability to step through the program is very helpful (can be built in to the program with the debugger; I mentioned earlier)
Remember to remove prior to shipping any code - doesn't just stop for testing!

---

Error Objects
EvalError is not used in the current ECMAScript specification and only retained for backwards compatibility. It was used to identify errors when using the global eval() function.
RangeError is thrown when a number is outside an allowable range of values.
ReferenceError is thrown when a reference is made to an item that doesn’t exist. For example, calling a function that hasn't been defined.
SyntaxError is thrown when there’s an error in the code’s syntax.
TypeError is thrown when there’s an error in the type of value used; for example, a string is used when a number is expected.
URIError is thrown when there’s a problem encoding or decoding the URI.
InternalError is a non-standard error that is thrown when an error occurs in the JavaScript engine. A common cause of this too much recursion.
const error = new Error(); Constructor function to create and the parameter is the error message -> const error = new Error("oops, something isn't right");

there are errors that are thrown automatically by the JavaScript engine when an error occurs. It’s also possible to throw your own exceptions using the throw statement
throw new Error('Something has gone badly wrong!');
This example shows the error to be efficient in explaining the problem - not just NaN

function squareRoot(number) {
'use strict';
if (number < 0) {
throw new RangeError('You can't find the square root of negative numbers')
}
return Math.sqrt(number);
};
Handling the Exceptions
-- using try, catch, and finally we can 'try' and run the code, 'catch' the error to be able to return an acceptable answer and continue the program... for example
function imaginarySquareRoot(number) {
'use strict';
try {
return String(squareRoot(number));
} catch(error) {
return squareRoot(-number)+'i';
}
}

Finally will always execute after the try or catch and will be useful if something should happen in both cases, see below
function imaginarySquareRoot(number) {
'use strict';
let answer;
try {
answer = String(squareRoot(number));
} catch(error) {
answer = squareRoot(-number)+"i";
} finally {
return `+ or - ${answer}`;
}
}
We can always run tests to check for valid functions
Test-Driven Development TDD
1. Write tests (that initially fail)
2. Write code to pass the tests
3. Refactor the code
4. Test refactored code
5. Write more tests for new features
one application -- Jest - Facebook framework (nmp install -g jest)
Example showing factors
function factorsOf(n) {
const factors = [];
for (let i=1; i <= n ; i++) { // change on this line
if (n/i === Math.floor(n/i)){
factors.push(i);
}
}
return factors;
}
Dont foget to tidy up code - refactoring
then, implement sort(); as well as throwing some exceptions
function factorsOf(n) {
const factors = [];
for (let i=1 , max = Math.sqrt(n); i <= max ; i++) {
if (n%i === 0){
factors.push(i,n/i);
}
}
return factors.sort((a,b) => a - b);
}
and to check if is prime
function isPrime(n) {
try{
return factorsOf(n).length === 2;
} catch(error) {
return false;
}
}

---

Chapter Summary
- Novice to Ninja JavaScript
Bugs are unavoidable in code, and it’s best to find them early rather than later.
JavaScript can be put into strict mode using the string "use strict" . This can be used in a whole file or just a single function.
Linting tools can be used to ensure your code follows good practice and conventions.
Feature detection can check whether a method is supported before calling it, helping to avoid an exception being thrown.
The console and browser’s built-in debugging tool can be used to interactively find and fix bugs in code.
Exceptions can be thrown using the throw statement.
An error object is created when an exception occurs.
Any code placed inside a try block will pass any error objects to a catch block when an exception occurs. Any code inside a finally block will run if an exception does or does not occur.
Test-driven development is the practice of writing tests that fail, then writing the code that passes the test, then refactoring the code every time a new feature is implemented.