goog.require('goog.debug.ErrorHandler'); is missing

[GoogleCodeExporter]

goog.require('goog.debug.ErrorHandler'); is missing in goog.events.events.js

thats all

Original issue reported on code.google.com by dan...@steigerwald.cz on 4 Dec 2011 at 1:25

[GoogleCodeExporter]

http://code.google.com/p/closure-library/wiki/FrequentlyAskedQuestions#When_I_co
mpile_with_type-checking_on,_I_get_warnings_about_unkno

Original comment by Nicholas.J.Santos on 4 Dec 2011 at 2:44

• Changed state: Invalid

[GoogleCodeExporter]

Issue 493 has been merged into this issue.

Original comment by pall...@google.com on 30 Aug 2012 at 7:49

[GoogleCodeExporter]

As noted in 493, I don't believe this is invalid. This error occurs in only one 
file.

If this were correct behavior, why would this error not occur in other files?  

Instead of claiming user error and having to add instructions to the FAQ, why 
not add the one line to this one file?

My compilation includes the everything under closure-library, which should 
include the deps.js file, but the error remains.  The require() call is missing 
from this file and the unit test doesn't catch the issue because it has the 
require() call that is missing from events.js.

http://codereview.appspot.com/6506048/

Original comment by Bitwise...@gmail.com on 31 Aug 2012 at 5:14

[GoogleCodeExporter]

Because that would be wrong. goog.require'ing a file will cause the file to be 
included in compilation, even though it may be completely unused. The compiler 
can not remove statics, so this may unintentionally enlarge the size of the 
compiled binary.

The rule of thumb is that you should only pull the file if you directly use 
stuffs defined in the file (e.g., when you call new foo.Bar, or when accessing 
statics defined on the file). Types appearing only in comments is not a direct 
use. Presumably, when the method is called from another file, that other file 
will need to directly/indirectly require the type to create the object.

If you have problem with using deps.js, feel free to send an email to 
closure-library-discuss@googlegroups.com

Original comment by chrishe...@google.com on 4 Sep 2012 at 6:34

[GoogleCodeExporter]

Ah, interesting. Okay.

I have no problem with using deps.js.  I'm generating it via depswriter.py and 
using it on my pages when loading uncompiled.   For compilation, I'm using the 
closurebuilder.py script per the instructions at 
https://developers.google.com/closure/library/docs/closurebuilder .  From that 
page, it seems one of the features of that script is to detect the files 
required for compilation of a provided namespace.  My deps.js file is in one of 
the folders I listed as a "root".  I also reference the closure library as a 
"root".   

The instructions for depswriter (linked to from the FAQ page above) don't help 
solve this issue. 

closurebuilder is where we're telling people to start,  I would argue that I 
should get no compilation warnings or errors from inside the the closure 
library when using the included script, even with the warnings turned all the 
way up.   

The fix is to explicitly reference the deps.js that is under 
closure-library/closure/goog.  Is that correct?   

We can identify the problem, we can describe exactly how to mitigate it.  
Wouldn't it be better to solve this with code instead of passing it off for 
users to stumble on and dig for a workaround?   Should I file a feature 
request?  

I'll at least go ahead and update the wiki page to be a little more specific.  
Since this problem surfaces in closurebuilder, could we update 
https://developers.google.com/closure/library/docs/closurebuilder to say 
something about it and link to the FAQ page? 

Original comment by Bitwise...@gmail.com on 5 Sep 2012 at 5:55

[GoogleCodeExporter]

Updated http://code.google.com/p/closure-library/wiki/FrequentlyAskedQuestions. 

Original comment by Bitwise...@gmail.com on 5 Sep 2012 at 9:01

[GoogleCodeExporter]

Thanks for updating the wiki! (:

Original comment by chrishe...@google.com on 6 Sep 2012 at 9:57