HTML and CSS Reference
In-Depth Information
}
return false;
}
}
As you can see from the preceding code, the main changes are that the
isTypeOf
method checks to see whether the type parameter is a string type or
not. If it's a string, the assumption is that you want to check for a primitive type;
otherwise, you're going to check for an object type. If the primitive type is the
same as the type you require, it will return true.
This is by no means a bulletproof solution. There are libraries available that can
do even better type checking. The idea is that as you begin to require more
validation techniques, you can add to the validation object as and when you
need to. If a validation method that you create doesn't quite match up to a
specific edge case, you can adjust to compensate. With these in place, we can
now enforce type in the models' accessor methods based on the UML class
diagrams.
Applying Validation to Models
When you apply validation to models, you have one of two choices: either you
fail silently if the validation fails, or you throw an exception and allow the caller
to handle it. I prefer the later. Nothing is more frustrating than when something
seriously bad happens in your application and you have no idea about it and,
thus, can't react to it in your code.
Throwing and Handling Exceptions
Exceptions should be known as critical errors that can be thrown by user code.
You shouldn't throw an exception in every bit of code that you write, as you
have to wrap that code from the caller in
try
/
catch
blocks in the code calling it.
An uncaught thrown exception will appear in the console of the browser.
Throwing an exception is fairly simple. It consists of the throw operator along
with either a string, Boolean, integer, or (believe it or not) an object.
// Throwing a string
if(true !== false){
throw "True definitely isn't equal to false"
}
// Throwing an object
if(true !== false){
throw {
message: "True definitely isn't equal to false",
