Or if we were lucky enough to witness the error, we might have ended up doing large refactorings and adding a lot of different code that we’re forced to dig through. We might not have tested the feature thoroughly enough, so we might never actually run into a potential error that would be thrown! If we add just a bit of code, save our file, re-run the code, and immediately see the error, we might be able to isolate the problem quickly but that’s not always the case. Most people don’t like to get any sorts of errors when running their code - those are considered bugs!Īnd when we write new code, we try our best to avoid introducing new bugs. Think back to that TypeError we got earlier from trying to call a string as a function. The alternative is to use a static type system to make predictions about what code is expected before it runs. JavaScript only truly provides dynamic typing - running the code to see what happens. Seen in this way, a type is the concept of describing which values can be passed to fn and which will crash. This kind of behavior makes it hard to predict what the code will do before it runs, which means it’s harder to know what your code is going to do while you’re writing it. The only way in pure JavaScript to tell what fn does with a particular value is to call it and see what happens.
We can observe by reading the code that this function will only work if given an object with a callable flip property, but JavaScript doesn’t surface this information in a way that we can check while the code is running.
0 kommentar(er)
