14 Matching Annotations
  1. Jan 2022
    1. Seems easy, right? How about the below code, what will it print? new Promise((_, reject) => reject(new Error('woops'))). catch(error => { console.log('caught', err.message); }); It'll print out an unhandled rejection warning. Notice that err is not defined!
  2. Aug 2021
  3. Apr 2021
  4. Feb 2021
    1. we also wrap them in Failure to solve the second problem: spotting potential exceptions is hard
    2. Almost everything in python can fail with different types of exceptions: division, function calls, int, str, generators, iterables in for loops, attribute access, key access, even raise something() itself may fail. I am not even covering IO operations here. And checked exceptions won’t be supported in the nearest future.
    3. You still need to have a solid experience to spot these potential problems in a perfectly readable and typed code.
    4. print will never be actually executed. Because 1 / 0 is an impossible operation and ZeroDivisionError will be raised.
  5. Dec 2020
  6. Oct 2020
  7. Sep 2020
    1. The problem I have with this approach to state and prop variables is that the difference between them is very blurry. In React you can clearly see that a prop is an input to component (because of clear function notation), and that state is something internal. In Svelte they are both just variables, with the exception that props use export keyword.

      This is something I've seen before: people noticing that Svelte is missing some kind of naming convention.

      React has use___ convention, for example. Without that, it makes it hard to see the difference between and know just from the name that a function is an (mentioned in the other article I read) action and not a event handler or even component, for example.

    1. Just throwing in <div class="{$$props.class || ''} otherChildClass"></div> seems the easiest, and it'll avoid undefined classes. I feel like many aren't noticing the undefined values getting inserted in their classes.
  8. May 2020
    1. These options have almost deceptively similar wordings, with only subtle difference that is too hard to spot at a glance (takes detailed comparison, which is fatiguing for a user):

      1. can use your browser’s information for providing advertising services for this website and for their own purposes.
      2. cannot use your browser’s information for purposes other than providing advertising services for this website.

      If you rewrite them to use consistent, easy-to-compare wording, then you can see the difference a little easier:

      1. can use your browser’s information for providing advertising services for this website and for their own purposes.
      2. can use your browser’s information for providing advertising services for this website <del>and for their own purposes</del>.

      Standard Advertising Settings

      This means our ad partners can use your browser’s information for providing advertising services for this website and for their own purposes.

      Do Not Share My Information other than for ads on this website

      This means that our ad partners cannot use your browser’s information for purposes other than providing advertising services for this website.

    1. I reckon that it was: less a communication failure more a failure to pay attention – no disrespect intended. Given the unfortunate coincidence, it's almost entirely understandable that everyone concerned lost sight of Mozilla's forewarning.