Loading ...
Sorry, an error occurred while loading the content.

Catch block identifier reuse flagged as error

Expand Messages
  • Joshua
    The following generates the error e is already defined. : function f() { try { } catch (e) { } try { } catch (e) { }} The identifier e is bound to
    Message 1 of 7 , May 28, 2010
    View Source
    • 0 Attachment
      The following generates the error "'e' is already defined.":
      function f() { try { } catch (e) { } try { } catch (e) { }}
      The identifier "e" is bound to the lexical environment of each catch
      block, so it is not "already defined" within the scope of the function,
      which is what the error seemingly refers to.
      A warning for this case makes far more sense:
      function f() { var e = 1; try { } catch (e) { } try { } catch
      (e) { }}
      And JSLint does correctly report two errors. To those unfamiliar with
      the language, it would be unclear what "e" refers to at various points
      in f. I wholeheartedly endorse a JSLint error in this case!
      Likewise, JSLint very correctly reports an error here, where "e" is not
      defined outside of the catch block:
      function f() { try { } catch (e) { } f(e);}
      Now, obviously, one can write this instead:
      function f() { try { } catch (e1) { } try { } catch (e2) { }}
      ... but I'm not convinced that this improves readability; I think it
      impairs it by adding unnecessary clutter. Even using the same identifier
      name in both catch clauses, the syntax of the program makes it explicit
      that inside the second catch block, the identifier "e" can only be
      referring to the value thrown by the second try block.
      This is minor in the grand scheme of things, and I happily defer to our
      benevolent dictator.



      [Non-text portions of this message have been removed]
    • Joshua Bell
      (1) apologies for the formatting - the Yahoo! Groups interface helpfully offered a rich text editor, then apparently discarded the results both for email and
      Message 2 of 7 , May 28, 2010
      View Source
      • 0 Attachment
        (1) apologies for the formatting - the Yahoo! Groups interface helpfully
        offered a rich text editor, then apparently discarded the results both for
        email and for the web interface to the group (
        http://tech.groups.yahoo.com/group/jslint_com/message/1327)

        (2) Re-reading my post, the last line could be taken as sarcasm, snark,
        objection to a process, or disrespectful to those living
        under oppressive regimes. None of those were intended - I'm truly happy with
        Crockford's creation, maintenance, ownership of and vision for jslint.

        On Fri, May 28, 2010 at 10:48 AM, Joshua <josh@...> wrote:

        > The following generates the error "'e' is already defined.":
        > function f() { try { } catch (e) { } try { } catch (e) { }}
        > The identifier "e" is bound to the lexical environment of each catch
        > block, so it is not "already defined" within the scope of the function,
        > which is what the error seemingly refers to.
        > A warning for this case makes far more sense:
        > function f() { var e = 1; try { } catch (e) { } try { } catch
        > (e) { }}
        > And JSLint does correctly report two errors. To those unfamiliar with
        > the language, it would be unclear what "e" refers to at various points
        > in f. I wholeheartedly endorse a JSLint error in this case!
        > Likewise, JSLint very correctly reports an error here, where "e" is not
        > defined outside of the catch block:
        > function f() { try { } catch (e) { } f(e);}
        > Now, obviously, one can write this instead:
        > function f() { try { } catch (e1) { } try { } catch (e2) { }}
        > ... but I'm not convinced that this improves readability; I think it
        > impairs it by adding unnecessary clutter. Even using the same identifier
        > name in both catch clauses, the syntax of the program makes it explicit
        > that inside the second catch block, the identifier "e" can only be
        > referring to the value thrown by the second try block.
        > This is minor in the grand scheme of things, and I happily defer to our
        > benevolent dictator.
        >
        >
        >
        > [Non-text portions of this message have been removed]
        >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
        >


        [Non-text portions of this message have been removed]
      • D Chiesa
        It does not happen only in catch blocks. JSLINT will flag the 2nd e in this code as well: if (condition1) { var e = new Error( This is unacceptable! );
        Message 3 of 7 , May 28, 2010
        View Source
        • 0 Attachment
          It does not happen only in catch blocks.
          JSLINT will flag the 2nd e in this code as well:

          if (condition1) {
          var e = new Error("This is unacceptable!");
          e.source = "Whatever";
          throw e;
          }

          if (condition2){
          var e = new Error("Some other problem occurred");
          throw e;
          }






          From: Joshua
          Sent: Friday, May 28, 2010 1:48 PM
          To: jslint_com@yahoogroups.com
          Subject: [jslint] Catch block identifier reuse flagged as error



          The following generates the error "'e' is already defined.":
          function f() { try { } catch (e) { } try { } catch (e) { }}
          The identifier "e" is bound to the lexical environment of each catch
          block, so it is not "already defined" within the scope of the function,
          which is what the error seemingly refers to.
          A warning for this case makes far more sense:
          function f() { var e = 1; try { } catch (e) { } try { } catch
          (e) { }}
          And JSLint does correctly report two errors. To those unfamiliar with
          the language, it would be unclear what "e" refers to at various points
          in f. I wholeheartedly endorse a JSLint error in this case!
          Likewise, JSLint very correctly reports an error here, where "e" is not
          defined outside of the catch block:
          function f() { try { } catch (e) { } f(e);}
          Now, obviously, one can write this instead:
          function f() { try { } catch (e1) { } try { } catch (e2) { }}
          ... but I'm not convinced that this improves readability; I think it
          impairs it by adding unnecessary clutter. Even using the same identifier
          name in both catch clauses, the syntax of the program makes it explicit
          that inside the second catch block, the identifier "e" can only be
          referring to the value thrown by the second try block.
          This is minor in the grand scheme of things, and I happily defer to our
          benevolent dictator.

          [Non-text portions of this message have been removed]





          [Non-text portions of this message have been removed]
        • Aseem Kishore
          http://www.jslint.com/lint.html#scope That said, I m unclear about try-catch blocks because we re not declaring var e ; e is an implicit variable just like
          Message 4 of 7 , May 28, 2010
          View Source
          • 0 Attachment
            http://www.jslint.com/lint.html#scope

            That said, I'm unclear about try-catch blocks because we're not declaring
            "var e"; e is an implicit variable just like function arguments. I would
            certainly love to be able to re-use the same variable name, just as we can
            do otherwise.

            function foo(x) {
            // x is already "declared"
            alert(x);
            // re-use x, no problem
            x = 5;
            // similarly, e is already "declared"
            try { throw "oops"; } catch (e) { }
            // so we should be able to re-use e as well, no?
            try { throw "again"; } catch (e) { }
            // but instead, JSLint returns an error for re-using e.
            }

            Aseem

            On Fri, May 28, 2010 at 11:09 AM, D Chiesa <dpchiesa@...> wrote:

            >
            >
            > It does not happen only in catch blocks.
            > JSLINT will flag the 2nd e in this code as well:
            >
            > if (condition1) {
            > var e = new Error("This is unacceptable!");
            > e.source = "Whatever";
            > throw e;
            > }
            >
            > if (condition2){
            > var e = new Error("Some other problem occurred");
            > throw e;
            > }
            >
            > From: Joshua
            > Sent: Friday, May 28, 2010 1:48 PM
            > To: jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>
            > Subject: [jslint] Catch block identifier reuse flagged as error
            >
            > The following generates the error "'e' is already defined.":
            > function f() { try { } catch (e) { } try { } catch (e) { }}
            > The identifier "e" is bound to the lexical environment of each catch
            > block, so it is not "already defined" within the scope of the function,
            > which is what the error seemingly refers to.
            > A warning for this case makes far more sense:
            > function f() { var e = 1; try { } catch (e) { } try { } catch
            > (e) { }}
            > And JSLint does correctly report two errors. To those unfamiliar with
            > the language, it would be unclear what "e" refers to at various points
            > in f. I wholeheartedly endorse a JSLint error in this case!
            > Likewise, JSLint very correctly reports an error here, where "e" is not
            > defined outside of the catch block:
            > function f() { try { } catch (e) { } f(e);}
            > Now, obviously, one can write this instead:
            > function f() { try { } catch (e1) { } try { } catch (e2) { }}
            > ... but I'm not convinced that this improves readability; I think it
            > impairs it by adding unnecessary clutter. Even using the same identifier
            > name in both catch clauses, the syntax of the program makes it explicit
            > that inside the second catch block, the identifier "e" can only be
            > referring to the value thrown by the second try block.
            > This is minor in the grand scheme of things, and I happily defer to our
            > benevolent dictator.
            >
            > [Non-text portions of this message have been removed]
            >
            > [Non-text portions of this message have been removed]
            >
            >
            >


            [Non-text portions of this message have been removed]
          • D Chiesa
            Thank you, I ve been enlightened. ... From: Aseem Kishore Sent: Friday, May 28, 2010 2:15 PM To:
            Message 5 of 7 , May 28, 2010
            View Source
            • 0 Attachment
              Thank you, I've been enlightened.

              --------------------------------------------------
              From: "Aseem Kishore" <aseem.kishore@...>
              Sent: Friday, May 28, 2010 2:15 PM
              To: <jslint_com@yahoogroups.com>
              Subject: Re: [jslint] Catch block identifier reuse flagged as error

              > http://www.jslint.com/lint.html#scope
              >
              > That said, I'm unclear about try-catch blocks because we're not declaring
              > "var e"; e is an implicit variable just like function arguments. I would
              > certainly love to be able to re-use the same variable name, just as we can
              > do otherwise.
              >
              > function foo(x) {
              > // x is already "declared"
              > alert(x);
              > // re-use x, no problem
              > x = 5;
              > // similarly, e is already "declared"
              > try { throw "oops"; } catch (e) { }
              > // so we should be able to re-use e as well, no?
              > try { throw "again"; } catch (e) { }
              > // but instead, JSLint returns an error for re-using e.
              > }
              >
              > Aseem
              >
              > On Fri, May 28, 2010 at 11:09 AM, D Chiesa <dpchiesa@...> wrote:
              >
              >>
              >>
              >> It does not happen only in catch blocks.
              >> JSLINT will flag the 2nd e in this code as well:
              >>
              >> if (condition1) {
              >> var e = new Error("This is unacceptable!");
              >> e.source = "Whatever";
              >> throw e;
              >> }
              >>
              >> if (condition2){
              >> var e = new Error("Some other problem occurred");
              >> throw e;
              >> }
              >>
              >> From: Joshua
              >> Sent: Friday, May 28, 2010 1:48 PM
              >> To: jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>
              >> Subject: [jslint] Catch block identifier reuse flagged as error
              >>
              >> The following generates the error "'e' is already defined.":
              >> function f() { try { } catch (e) { } try { } catch (e) { }}
              >> The identifier "e" is bound to the lexical environment of each catch
              >> block, so it is not "already defined" within the scope of the function,
              >> which is what the error seemingly refers to.
              >> A warning for this case makes far more sense:
              >> function f() { var e = 1; try { } catch (e) { } try { } catch
              >> (e) { }}
              >> And JSLint does correctly report two errors. To those unfamiliar with
              >> the language, it would be unclear what "e" refers to at various points
              >> in f. I wholeheartedly endorse a JSLint error in this case!
              >> Likewise, JSLint very correctly reports an error here, where "e" is not
              >> defined outside of the catch block:
              >> function f() { try { } catch (e) { } f(e);}
              >> Now, obviously, one can write this instead:
              >> function f() { try { } catch (e1) { } try { } catch (e2) { }}
              >> ... but I'm not convinced that this improves readability; I think it
              >> impairs it by adding unnecessary clutter. Even using the same identifier
              >> name in both catch clauses, the syntax of the program makes it explicit
              >> that inside the second catch block, the identifier "e" can only be
              >> referring to the value thrown by the second try block.
              >> This is minor in the grand scheme of things, and I happily defer to our
              >> benevolent dictator.
              >>
              >> [Non-text portions of this message have been removed]
              >>
              >> [Non-text portions of this message have been removed]
              >>
              >>
              >>
              >
              >
              > [Non-text portions of this message have been removed]
              >
              >
              >
              > ------------------------------------
              >
              > Yahoo! Groups Links
              >
              >
              >
              >
            • Michael Lorton
              That s not a JSLint bug, that s a Javascript-specification bug. Local variables are function-scoped and not, as they should be, block-scoped. The following
              Message 6 of 7 , May 28, 2010
              View Source
              • 0 Attachment
                That's not a JSLint bug, that's a Javascript-specification bug. Local variables are function-scoped and not, as they should be, block-scoped. The following function will return "3" when it should return undefined:

                (function() {
                if (true) {
                var v = 3;
                }
                if (true) {
                var v;
                return v;
                }
                })();


                JSLint is pointing out that Javascript will not do what you obviously want. By contrast:
                (function() {
                var e = "no problem";
                try {
                a();
                } catch(e) {
                return String(e) ;
                }
                return e;
                })();


                does exactly what you want: returns the text of the exception if one is thrown.



                ________________________________
                From: D Chiesa <dpchiesa@...>
                To: jslint_com@yahoogroups.com
                Sent: Fri, May 28, 2010 11:09:09 AM
                Subject: Re: [jslint] Catch block identifier reuse flagged as error

                It does not happen only in catch blocks.
                JSLINT will flag the 2nd e in this code as well:

                if (condition1) {
                var e = new Error("This is unacceptable!");
                e.source = "Whatever";
                throw e;
                }

                if (condition2){
                var e = new Error("Some other problem occurred");
                throw e;
                }






                From: Joshua
                Sent: Friday, May 28, 2010 1:48 PM
                To: jslint_com@yahoogroups.com
                Subject: [jslint] Catch block identifier reuse flagged as error



                The following generates the error "'e' is already defined.":
                function f() { try { } catch (e) { } try { } catch (e) { }}
                The identifier "e" is bound to the lexical environment of each catch
                block, so it is not "already defined" within the scope of the function,
                which is what the error seemingly refers to.
                A warning for this case makes far more sense:
                function f() { var e = 1; try { } catch (e) { } try { } catch
                (e) { }}
                And JSLint does correctly report two errors. To those unfamiliar with
                the language, it would be unclear what "e" refers to at various points
                in f. I wholeheartedly endorse a JSLint error in this case!
                Likewise, JSLint very correctly reports an error here, where "e" is not
                defined outside of the catch block:
                function f() { try { } catch (e) { } f(e);}
                Now, obviously, one can write this instead:
                function f() { try { } catch (e1) { } try { } catch (e2) { }}
                ... but I'm not convinced that this improves readability; I think it
                impairs it by adding unnecessary clutter. Even using the same identifier
                name in both catch clauses, the syntax of the program makes it explicit
                that inside the second catch block, the identifier "e" can only be
                referring to the value thrown by the second try block.
                This is minor in the grand scheme of things, and I happily defer to our
                benevolent dictator.

                [Non-text portions of this message have been removed]





                [Non-text portions of this message have been removed]



                ------------------------------------

                Yahoo! Groups Links



                [Non-text portions of this message have been removed]
              • Michael Lorton
                From: D Chiesa ... Then tell us, does Javascript have a Buddha-nature? M.
                Message 7 of 7 , May 28, 2010
                View Source
                • 0 Attachment
                  From: D Chiesa <dpchiesa@...>

                  > Thank you, I've been enlightened.

                  Then tell us, does Javascript have a Buddha-nature?

                  M.
                Your message has been successfully submitted and would be delivered to recipients shortly.