Dustin Deus
Dustin Deus
yes, `(40 minutes total)` is confusing. I'd remove it.
Hi @Jeff-Mott-OR my distinction is to explain that throwing errors shouldn't be used for everything. As long as you can handle the error you shouldn't throw an error you should...
No, I don't want to promise all the things you should use the tool of you choice to handle asynchronous stuff but you shouldn't throw errors just to catch them...
He puts it in a nutshell: > One should avoid throw errors as the way to pass error conditions around in applications. The throw statement should only be used "For...
I'm on your side but it doesn't answer that question. This article is worth to read https://www.joyent.com/node-js/production/design/errors > As we'll see, it's very uncommon to need to catch an error...
I think we are moving from the suggestion I had. I am addressing a special case with asynchronous and synchronous error handling. I think we can agree with: **Operational errors**,...
@lavinle an example: #### In general, using throw and expecting a caller to use try/catch is pretty rare expect for JSON.parse __Bad:__ ```js function divide(a, b) { if (b ===...
I can reproduce it. ```css :global .page { padding: 20px; } ``` produces this in `scopeBehaviour: local` scope ```css .page { padding: 20px; } ``` but this in `scopeBehaviour: global`...
I also need to listen to `onChange` to recognize user values which aren't part of the suggestion. I recommend to just consume the places lib directly. The repo seems not...