If we don't want parser to 'recover' from errors, how to disable recovery and
just let exception slip out in antlr3 ?
I get a solution on http://www.antlr.org/pipermail/antlr-interest/2006-September/017536.html
But it doesn't work.
Your posted link is pretty much spot on.
You override the error recovery methods, mismatch is only one of them, There are a few, depending on the error.
I don't have the code in front of me right now, but look at all the mismatch methods in the parser file.
Related
Sometimes, we use libraries that are pretty much well debugged and are usually not a cause of an error. Still, these libraries can return errors due to our misuse of their API. In such case, the steps internal to these libraries show up within the backtrace of an error, which are just garbage from the point of view of the programmers using the library, and make it difficult to spot the cause of the error. Even some methods in the core Ruby insert some internal steps into the backtrace. For example, whenever you see a backtrace involving Enumerable#inject, there is always Enumerable#each being called from it, which shows up in the backtrace and is annoying.
What is a good way to remove from the backtrace the steps internal to certain given libraries? I am currently dong it by parsing the backtrace and filtering it by the file name. Is there a better way to do it?
When you are writing a library by yourself, is there a good way to suppress the internal steps appearing in a backtrace involving a method call that uses the library? An obvious way might be to insert a pair of rescue and raise for every method that is to be used from outside of the library, but that does not seem right.
Well...
There isn't really a better way to filter. If you can get the full filepath for the backtrace, though, you can filter by directory which can rule out all stdlibs and gems. Beyond that, it's more trouble than it's worth.
There is a much better solution for this. However, it requires that you catch all exception thrown by Ruby in your library, and then rethrow them after doing this (also do this to all your own excpetions). So wrap all your method with this:
begin
...
rescue Exception
e = $!
e.set_backtrace(caller(nesting_level))
raise e
end
The nesting_level is how many methods of this library the current method was called from. If it was called directly from user code, put 0. If it was called by one method that was called in user code, put in 1, and so on.
After playing with Code Analysis for a small project I am working on, I am wondering just how severe I should be when resolving code to be analytically compliant.
I know I can suppress warnings for this, but to me, suppressing a warning to some extent is a Cop-out (no pun intended..."FXCop").
Example warning:
Do not raise exceptions in unexpected
locations 'CustomObject.Equals(object)' creates an exception of type
'ArgumentException'. Exceptions should not be raised in this type of
method. If this exception instance might be raised, change this
method's logic so it no longer raises an exception.
Reason for throwing this...
CustomObject.Equals(object) might try and compare CustomObject to FooBarObject...which aren't even of the same type, so in this instance, should I throw an exception, or just return false?
In general, should I be really anal (for want of a better word) in making my code absolutely compliant, or will I come across situations where warning suppression will become necessary?
FxCop warnings are just warnings, they don't flag invalid code. That's the job of the compiler. The rules FxCop uses were collected from years of experience writing .NET code. They represent "best practices" and in general are there to remind you of unintended consequences and the more obscure parts of .NET programming, like CAS.
Always refer back to the documentation to see why the rule exists. For CA1065 you'll see:
An Equals method should return true or false instead of throwing an exception. For example, if Equals is passed two mismatched types it should just return false instead of throwing an ArgumentException.
Which exactly matches your usage, you'll have no trouble adopting the advice. Unfortunately it is a bit short on the exact reason the rule was created. Which really doesn't go beyond the "don't throw in unexpected places" guidance. The unintended consequence here is that another programmer that uses your class won't realize that a try/catch would be needed if he doesn't want the code to fail. Feel free to put a Debug.Assert() in your Equals method. There are plenty of cases where you'll want to ignore the advice, CA2000 is particularly prone to false warnings for example. Apply the [SuppressMessage] attribute if necessary to not have to look at it again.
I'm a noob and trying to convert an example from a book into an app I can use.
The sample app is a modified version of the contacts application and it works.
I've done some further modification, and the search no longer works. It sigabrts on the following line
self.filteredAnswercards = [flattenedArray
filteredArrayUsingPredicate:predicate];
I'm stumped.
my head is bloody from beating it against my keyboard.
ANY help is massively appreciated.
Thanks.
My suggestion was to wrap the line that crashes inside a #try/#catch block and, inside the catch, log the exception and the result of the exception's callStackSymbols method.
For the record, part of the problem with the 4.x versions of Xcode is that they are much worse than 3.x versions at telling you where an exception is coming from. For this reason, getting familiar with tricks that make a program or the debugger tell you what you need to know is very important.
I would guess that predicate is nil. Where did you assign it? Or did you never assign it?
Very hard to say without seeing more code. Sigabort generally means an exception has been thrown. You can put a break point in objc_exception_throwto get a back trace which should help highlight the cause.
If you get NO new info with the above, others have said that a full reboot of the computer can help... but I have not had a situation where I could verify this.
---- edit based on comments -----
It sounds like filteredAnswercards is nil, that will definitely cause a Sigabort. Allocate that array properly and you should be good to go.
As the title suggest, for example, in 85% of the situation, I'd like to check the return code of foo(), but sometimes I really don't care about it, but this will raise Coverity warning.
What's the best way to deal with this problem?
Changing Coverity settings doesn't count. :)
The correct way to suppress CHECKED_RETURN defect is to cast the return value you don't care about to a void. This has the additional advantage of making it clear to anyone reading the code that you don't care about return value, rather than that you forgot to check it.
I am trying to track down a non-exhaustive pattern in a libraries code. Specifically HDBC's mysql implementation. It is trying to match over types in my program and map them to mysql's types I believe. I can't seem to get a callstack for this error which means that since there are a number of parameters to the SQL query it is difficult to track down exactly what is causing it.
Is it possible to get a callstack in haskell so I would know which parameter was causing the error? Also I would think that this should be caught by the compiler since it should be able to look at my types and the patterns and make sure that there was a corresponding match.
You can use the GHCi debugger to identify where the exception is coming from.
I walk through a full example here.
You might also take a look at the Debug.Trace library.