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

Re: [jslint] Catch block identifier reuse flagged as error

Expand Messages
  • 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 1 of 7 , May 28, 2010
      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 2 of 7 , May 28, 2010
        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.