I recently noticed the new AggregateError object (ECMAScript 2021). Is there any cases or best practices where it is recommended to use it?
Description from the MDN wiki:
The AggregateError object represents an error when several errors need to be wrapped in a single error. It is thrown when multiple errors need to be reported by an operation, for example by Promise.any(), when all promises passed to it reject.
So, use it whenever the description fits - if you want to throw multiple errors at once.
Related
I'm working on a JS library, as a part of it, I built a parser for small sort of a markup language to enable users to use more complicated expressions. I wanted to know if it is a good practice to throw an exception if there is an error in internal expression syntax and let users use the function within the try/catch block, or if it's better for example to return false and inform the user that there was a parsing error some other way (possibly console)? I can't really tell if throwing an exceptions is common practice when building a library, I know that jQuery for example throws some errors in its source, but jQuery is huge framework-like library so I would expect that, but is it common for small size libraries?
The problem with throwing exceptions on parse errors is that once you throw an exception, it is very difficult to resume the parse. That means that the parser intends to give up as soon as it hits the first syntax error; in other words, that it expects the user to fix one error at a time.
It's possible that you currently don't do any error recovery, so this might not bother you. But it should.
Are you certain that you're not going to want to try error recovery, particularly after listening to your users grumbling about how they have to try the parse dozens or hundreds of times to find all of their errors? And when you do eventually start to implement error recovery, will you be happy about having to find and change every place where the parser in order to change the way it is called?
I came across this answer in a SO question:
'AFAIK expect waits internally for the related promises.'
Does anyone know if this is correct? I've searched the protractor documentation for an answer with no luck. Can anyone point out the correct place in the documentation where it say this?
If it is correct, it would save me a lot of work! We have over two hundred tests, and to prevent timeouts I am converting all these types of calls:
expect(parentDialog.getAttribute('class')).toContain('k-window-maximized');
to this:
parentDialog.getAttribute('class').then(function(cls) {
expect(cls).toContain('k-window-maximized');
});
This is definitely true. expect() is "patched" by jasminewd/jasminewd2 (used by protractor internally) to implicitly resolve promises. Quote from the README:
Enhances expect so that it automatically unwraps promises before
performing the assertion.
Here is an another documentation reference:
The WebDriver Control Flow > Protractor Adaptations
In other words, unless you need a real resolved value for further actions or calculations, you can safely pass a promise into expect():
expect(parentDialog.getAttribute('class')).toContain('k-window-maximized');
I am writing a Node.js application, and inside one of its code blocks various exceptions may be thrown (by 3rd party code I call). Now I want to react on these exceptions, hence I do:
try {
// Call 3rd party code
} catch (e) {
// Handle e
}
Basically, this works fine, but ... how do I differ between different exceptions?
They all unfortunately have Error as constructor, hence this is no viable way. I may use the message property, but of course this is not the nicest way (as I am dependent on the fact the the message will never change, which is - IMHO - more probable than that the constructor changes).
Any ideas?
PS: Concretely - I need to react on SSL error while trying to do a tls.connect. How do I detect that it's an SSL error?
Most errors that are system-level errors wrapped into javascript error objects will have a code property and errno you can compare against. The list is defined in uv.h in the node.js source code. That's probably your 2nd choice, with preference being
instanceof where possible
code or errno
message
But the fact is sometimes you just have to look at message. Given the dynamic and loose typing of javascript and the fact that exceptions in general don't play a big role in node.js, there will be cases where checking the message is the best you can do.
I would not recommend using a try/catch structure in Node, as I don't think it will work due to the asynchronous nature of Node (unless you're using basic, synchronous code).
Assuming you're utilizing asynchronous functions/packages, you'll probably have more luck checking the err status in a callback function.
In javascript, I have noticed two ways of throwing an error:
1)
throw "An error";
2)
throw new Error('An object error')
Is there any advantage of choosing one way over the other?
Is one considered a better practice?
Thanks
Basically, JavaScript is implicitly throwing an Error object with "An error" as the message when you use method one. Unless you need to throw a different kind of exception (for example, one that has different properties explaining the error) method one is fine.
However, if you plan on throwing more complex exceptions in the future, you'll need to use method 2, as you'll need to define which object you're throwing.
Basically, for this purpose both are equivalent. I'd go with method 2, since it will put you in the right mindset down the road ;)
An Error object has nice little extras like error.name and (in Firefox) error.stack.
If you need those, do throw an error explicitly. However, most people merely use the error.toString() method (often called implicitly). In the latter case it's overkill to create an Error object in the first place, so throwing a string works just as well.
What type of object should be thrown in JavaScript?
I see a lot of examples which throw a plain old string and there seems to be a semi-standard Error type. Should I prefer one over the other?
The Error object and specific error objects such as TypeError are fully standardized in the ECMAScript specification. There are, however, common non-standard properties of these objects available in most browsers.
You can throw whatever you like, so long as your error handling code knows what to do with the objects you throw, but there are advantages to using Error objects:
Consistency with handling errors thrown by native code, such as having a message property, so you don't have to write different code to handle native errors and your own errors;
Error objects in Mozilla and other browsers have very useful non-standard properties, such as fileName, lineNumber and stack. You only get these on Error objects and they can be very useful for debugging.