JavaScript catch parameter already defined

前端 未结 4 886
有刺的猬
有刺的猬 2021-02-01 05:57

I\'m trying to understand why I\'m getting the following error, not how to work around it.

Passing the following code to JSLint or JSHint yields the er

相关标签:
4条回答
  • 2021-02-01 06:36

    The specification is quite clear that any name defined a catch statement will do nothing more than shadow a surrounding name. Beyond that I would not consider these errors as nothing more than a warning. Just using pure intuition I believe that this is simply overzealous analysis on the part of the designer of those Lint tools.

    Since a catch block introduces a new scope, using the same name will simply shadow any similar names in the enclosing scope. This isn't necessarily a bad thing if you are aware of the semantics. If you are coding under the assumption that the enclosing err will be accessible than you'll need to change your assumptions.

    Specification

    The production Catch : catch ( Identifier ) Block is evaluated as follows:

    1. Let C be the parameter that has been passed to this production.
    2. Let oldEnv be the running execution context’s LexicalEnvironment.
    3. Let catchEnv be the result of calling NewDeclarativeEnvironment passing oldEnv as the argument.
    4. Call the CreateMutableBinding concrete method of catchEnv passing the Identifier String value as the argument.
    5. Call the SetMutableBinding concrete method of catchEnv passing the Identifier, C, and false as arguments. Note that the last argument is immaterial in this situation.
    6. Set the running execution context’s LexicalEnvironment to catchEnv.
    7. Let B be the result of evaluating Block.
    8. Set the running execution context’s LexicalEnvironment to oldEnv.
    9. Return B.

    NOTE No matter how control leaves the Block the LexicalEnvironment is always restored to its former state.

    0 讨论(0)
  • 2021-02-01 06:48

    Wrote to Douglas Crockford, author of JSLint, about this issue.

    There turns out to be a very valid reason after all...

    Douglas writes:

    Catch variables are not scoped correctly, so I recommend that you use a different name in each one.

    If you look at this similar StackOverflow question you'll note that PleaseStand started to touch on it. Not all browsers, especially historic ones, handle scoping correctly or consistently.

    JSLint recognizes that your code may work in one browser, but not in another, leaving a very nasty and subtle bug to track down. The warning is real.

    By using a different name, which, yes, doesn't feel clean or concise at all, because it isn't, happens to be the universal way of not running into the problem.

    Thank you Douglas for clarifying! Mystery solved.

    0 讨论(0)
  • 2021-02-01 06:48

    You can have a problem with reusing the same parameter name in sequential try-catches if you later need to refer to the error.

    If more than one catch was called, only the last one will be in scope for a finally or function scope expression.

    jsLint is conservative- if you can prevent a possible screw up with a unique variable, why not use it?

    0 讨论(0)
  • 2021-02-01 06:50

    Check this answer out: JSLint complaining about my try/catch

    As has mentioned, try opens a new block-scope. See https://developer.mozilla.org/en/JavaScript/Reference/Scope_Cheatsheet

    Indeed the top of the document explains that it's not all standard, but in ES5, section 12.14 the section on executing a catch block clearly defines MDC's description as standard:

    No matter how control leaves the Block the LexicalEnvironment is always restored to its former state.

    0 讨论(0)
提交回复
热议问题