What does I mean in pylint? I haven't seen an error message that starts with I before.
Based on https://docs.pylint.org/en/1.6.0/tutorial.html, I is not included in the following list
* (C) convention, for programming standard violation
* (R) refactor, for bad code smell
* (W) warning, for python specific problems
* (E) error, for much probably bugs in the code
* (F) fatal, if an error occurred which prevented pylint from doing
It's related to a C++ extension.
Consider adding this module to extension-pkg-whitelist if you want to perform analysis based on run-time introspection of living objects. (c-extension-no-member)
I found it in the source code (Pylint version 2.6.0):
"I1101": (
"%s %r has no %r member%s, but source is unavailable. Consider "
"adding this module to extension-pkg-whitelist if you want "
"to perform analysis based on run-time introspection of living objects.",
"c-extension-no-member",
"Used when a variable is accessed for non-existent member of C "
"extension. Due to unavailability of source static analysis is impossible, "
"but it may be performed by introspecting living objects in run-time.",
And also a list of the error codes here including the "I".
As for what I means:
if you can reproduce the message then i suggest generating Pylint reports then prints a list with all the error categories of your result. Hopefully the I category too.
To enable reports, when you run Pylint simply add the flag -rn or --reports=y
This documentation might help you understand more, so you could just disable this error if you wish to.
Related
With the following code, go vet does not show an "out of bounds" error as I would expect:
package main
func main() {
a := make([]string, 1)
a[2] = "foo"
}
From the go vet documentation:
Flag: -shift
Shifts equal to or longer than the variable's length.
If go vet is not the tool to catch these errors, what is? Compiling and/or testing the code will catch this, but I'm looking for a static analysis based tool.
Its true that Go vet is for catching suspicious runtime error, by using some heuristics. The first Para is exact regarding its work
Vet examines Go source code and reports suspicious constructs, such as Printf calls whose arguments do not align with the format string. Vet uses heuristics that do not guarantee all reports are genuine problems, but it can find errors not caught by the compilers.
also in documentation its mentioned that
Note that the tool does not check every possible problem and depends on unreliable heuristics.
also the code which you are using to check for vetting your package is something very difficult to find by those heuristics as you are using a dynamic slice which can be appended or modified at runtime.
thereby not a perfect heuristic can be thought about for that.
fmt.Printf("%d", "scsa", "DSD")
those heuristic can catch things like this it all depends on what the training data is.
So vet should be a tool to take a quick look whether there is some general mistake which has been missed by you (If It gets caught :-) )its nothing like a compile tool or runtime checker it just runs some heuristics on the plane code you have written.
also documentation provides a list of available checks some examples are
Assembly declarations,
Copying locks,
Printf family,
Methods,
Struct tags,
etc there are many, you can see and read the complete documentation
I am learning about compilers, specifically looking at 2-phase compilers, and am confused on the certain phases where errors are detected. Let's say we have something like:
int x, y;
x = x + y + z;
Where we are trying to reference a variable that has not been declared. I think this is an error that would be detected in the front-end of the compiler. But I don't know which sub-area of the front-end would detect this error.
The three parts to the front-end are: the scanner, the parser, and the context-free analyzer. The scanner reads every single character in a statement and splits the statement up into tokens. So, I could be wrong, but I don't think the error would be detected here. The parser checks to see if the statement is syntactically correct. Here is where I start to get confused. Even though z is undeclared, the syntax of the statement is technically correct, so would the error not be detected here either? The context-free analyzer uses the symbol table and syntax tree to check the program to see if it is semantically consistent with the language definition. Here it also does type checking. Would it be here that the error would be detected? Because at this point the compiler would look in the symbol table and notice that z doesn't have a type (or that it's not in there at all?). Or is this something that would be detected by the back-end of the compiler? If it is the back-end, I don't understand why that is the case. Any clarification would be highly appreciated. Thanks.
This is ultimately compiler-dependent, but typically this would come up at the semantic analysis level, which is still in the compiler front-end.
With a traditional compiler, this couldn't be done in the scanning phase because scanners use finite automata and the language of "strings that represent proper variable scoping" isn't regular. This also typically wouldn't be done as part of parsing, since parsing usually is about building up an AST and, if it were done bottom-up, the scoping information wouldn't be available at the time that the parser determined the structure of the code.
However, the semantic analyzer has all the information necessary to find this error - it has the AST and can use that to build a symbol table, walk through all the expressions in the code, and notice that z isn't anywhere in that symbol table.
I have build a website run heavy ajax and I'm really care about performance after I enable Strict warning(performance penalty) in firebug it shown me a lot of warning from system and jquery2.2.3 as below image.
Enabling the option Strict Warnings (performance penalty) means that you will also get JavaScript warnings, which are hints about correct usage, though they may not have any effect on the execution of the code.
Examples for this are already shown in your screenshot, like references to undefined variables or using a single equal sign in a statement, which may be a comparison.
Example causing such messages:
while (item = array[i]) {
...
}
In this case item is not declared via var or let before a value is assigned to it, so you'll get a "reference to undefined property" warning. And an assignment is used within the while condition, which will cause a "test for equality (==) mistyped as assignment (=)?" warning.
jQuery and other libraries make a lot of use of such constructs. That's why you see so many messages related to it.
The logs marked with <System> are coming from browser internal code and can be ignored by you. To see them you must also have Show Chrome Errors or Show Chrome Messages.
Using strict means browser will check many things like if variable is initialized before use. There is no syntax error etc
Basically, I'm trying to understand the difference between the "Break in Class Module" and "Break on Unhandled Errors" that appear in the Visual Basic 6.0 IDE under the following path:
Tools --> Options --> General --> Error Trapping
The three options appear to be:
Break on All Errors
Break in Class Module
Break on Unhandled Errors
Now, apparently, according to MSDN, the second option (Break in Class Module) really just means "Break on Unhandled Errors in Class Modules". Also, this option appears to be set by default (ie: I think its set to this out of the box).
What I am trying to figure out is, if I have the second option selected, do I get the third option (Break on Unhandled Errors) for free? In that, does it come included by default for all scenarios outside of the Class Module spectrum? To advise, I don't have any Class Modules in my currently active project. I have .bas modules though. Also, is it possible that by Class Mdules they may be referring to normal .bas Modules as well? (this is my second sub-question).
Basically, I just want the setting to ensure there won't be any surprises once the exe is released. I want as many errors to display as possible while I am developing, and non to be displayed when in release mode. Normally, I have two types of On Error Resume Next on my forms where there isn't explicit error handling, they are as follows:
On Error Resume Next ' REQUIRED
On Error Resume Next ' NOT REQUIRED
The required ones are things like, checking to see if an array has any length, if a call to its UBound errors out, that means it has no length, if it returns a value 0 or more, then it does have length (and therefore, exists). These types of Error Statements need to remain active even while I am developing. However, the NOT REQUIRED ones shouldn't remain active while I am developing, so I have them all commented out to ensure that I catch all the errors that exist.
Once I am ready to release the exe, I do a CTRL+H to find all occurrences of:
'On Error Resume Next ' NOT REQUIRED
(You may have noticed they are commented out)... And replace them with:
On Error Resume Next ' NOT REQUIRED
... The uncommented version, so that in release mode, if there are any leftover errors, they do not show to users.
For more on the description by MSDN on the three options (which I've read twice and still don't find adequate) you can visit the following link:
http://webcache.googleusercontent.com/search?q=cache:yUQZZK2n2IYJ:support.microsoft.com/kb/129876&hl=en&lr=lang_en%7Clang_tr&gl=au&tbs=lr:lang_1en%7Clang_1tr&prmd=imvns&strip=1
I’m also interested in hearing your thoughts if you feel like volunteering them (and this would be my tentative/totally optional third sub-question, that being, your thoughts on fall-back error handling techniques).
Just to summarize, the first two questions were, do we get option 3 included in all non-class scenarios if we choose option 2? And, is it possible that when they use the term "Class Module" they may be referring to .bas Modules as well? (Since a .bad Module is really just a class module that is pre-instantiated in the background during start-up).
Thank you.
I'll start with the first option. Break on all errors simply disables your error handlers. This is useful when you are attempting to debug after you've put in error handlers, because you can have errors in the handlers themselves, or you can lose track of where the error happened when the error bubbles up the containership heirarchy (errors that aren't handled in a procedure attempt to find a handler in a calling procedure, which can be confusing if you're trying to find the offending line of code).
Next, break on unhandled errors doesn't actually break in a class module if there is a line of code causing an error in there. If you have this option set, and you call a method in a class, and there's an error in the line of code in the method, you'll break on the line in your client that has the method call.
Break in class module goes to the line of code in the class that has the error. A caveat to this is that if you are working with an ActiveX EXE, the controlling setting is in its project rather than in the client project. That is, you can have break on all errors set in your client project, and break on unhandled errors set in your ActiveX EXE project, and you won't break in the class module because you are working with two separate processes.
I prefer personally to leave it set on break in class module, because it lets me drill down to the site of the error with greatest precision. This is before I start doing error handlers, though; at that point I generally bounce around all three, depending on what I'm trying to stabilize.
Finally, I do NOT recommend EVER using On Error Resume Next except in the context of inline error handling.
Yes, when you select "Break in class module", it DOES still break on unhandled errors, but it will also break on ANY errors in class modules (not plain modules) that aren't handled in the class module itself.
Contrast this to "break on unhandled errors" which will cause it to exit out of the class/user control code when an error occurs inside it making it difficult to track down the exact location.
It's probably best to leave it set on the "break on unhandled errors" for general development as the others WILL get annoying when you have handled errors that are benign. Note that it's best to try and detect these before they trigger an error though.
Does ruby allow you to treat warnings as errors?
One reason I'd like to do this is to ensure that if heckle removing a line of code means that a warning occurs, I have the option of ensuring that the mutant get killed.
There is unfortunately no real way of doing this, at least not on most versions of Ruby out there (variations may exist), short of monitoring the program output and aborting it when a warning appears on standard error. Here's why:
Ruby defines Kernel.warn, which you can redefine to do whatever you wish (including exiting), and which you'd expect (hope) to be used consistently by Ruby to report warnings (including internal e.g. parsing warning), but
methods implemented natively (in C) inside Ruby will in turn directly invoke a native method called rb_warn from source/server.c, completely bypassing your redefinition of Kernel.warn (e.g. the "string literal in condition" warning, for example, issued when doing something like: do_something if 'string', is printed via the native rb_warn from source/parse.c)
to make things even worse, there is an additional, rb_warning native method, which can be used by Ruby to log warnings if -w or -v is specified.
So, if you need to take action solely on warnings generated by your application code's calling Kernel.warn then simply redefine Kernel.warn. Otherwise, you have exactly two options:
alter source/error.c to exit in rb_warn and rb_warning (and rb_warn_m?), and rebuild Ruby
monitor your program's standard error output for ': warning:', and abort it on match
You can finally do that by overriding Warning.warn like
module Warning
def warn(msg)
raise msg
end
end
This will turn the warning into an exception. This solution works at least since 2.4 branch.
You could also potentially use DTrace, and intercept the calls to rb_warn and rb_warning, though that's not going to produce exceptions you can rescue from somewhere. Rather, it'll just put them somewhere you can easily log them.