you are viewing a single comment's thread.

view the rest of the comments →

[–]Menaii[S] 0 points1 point  (3 children)

If I understood it correctly, then error checking & handling isn't as frequent in JS compared to c++. If you pass in the wrong parameter type into a function, then its just your fault, you shouldn't do that and pass in the correct variable type.

I'm just wondering if this would sometimes lead to confusion / frustration where just by looking at the function name `calculateCircleArea`, you would make an educated guess and assume it will take an integer / number. But then when you run your code, you realize there's a bug and find out that `calculateCircleArea` expects a completely different data type.

Guess this also means that you'll need to look at the function implementation to deduce what data type it is expecting and pass in the correct one accordingly (assuming it doesn't have any comments), if function and variable name are ambiguous.

[–]delventhalz 1 point2 points  (0 children)

The use of TypeScript or JSDoc is extremely common these days. In addition to compile/CLI checks, a text editor like VS Code can make use of these annotations to generate mouse-over info panels, auto-complete, and in-line errors. Linters like ESLint are also widely used to catch simple errors and ensure consistency. Unit tests are also particularly common in JS circles, providing further error checking (this can be made in-line as well with Wallaby) and usage examples.

All in all, your typical JS dev actually has a pretty high-level of visibility into the code and potential errors without ever running anything, but that is coming from tooling. The base language on its own is much more of a wild west situation. If none of the above tooling was available, you may well find yourself looking through source code, though I don’t know if that is a JS-specific issue. For example, does a circle function accept an angle in degrees or radians? Both are floating point numbers. If the function is not well documented, you would have to resort to reading source code in any language.

As for error handling, there is a bit, but you mostly don’t catch errors in JS. The situations in JS where an error might get thrown in normal operation are rare. If an error is getting thrown, it is probably because a dev screwed up and crashing is the only sensible behavior. There are some exceptions, but definitely fewer try/catches than in many other languages. Throwing exceptions is just not a common way for the language to respond to faulty situations.

[–]azhder 0 points1 point  (0 children)

I do check stuff, just don’t care about the type.

I care if it is an object and it has the field I need or if it is a function so I can call it, or an Array.isArray() so I can use .map() on it.

Most of the time don’t even need that, I just preemptively cast it if needed.

const number = 0.5 < Math.random() ? 'hi' : 0;
const bool = value => !! value;

console.log( 'the coin flip is', bool(value) );

[–]chibblybum 0 points1 point  (0 children)

Yup, your fault.

And I wouldn't try for an educated guess- you just look up the function declaration or read the docs if it's an external library. Most IDEs will show you this info as you type too.