I have a grammar where a language statement (outside of flow statements) is comprised of <expression>;. Currently, when ANTLR parses and finds the missing ;, it identifies it as missing at the position of the next token, which generally means the start of the next line. This is less than ideal, since in this case it is more correct to say it is missing at the end of the previous token, rather than the start of the next.
Is there a way to instruct ANTLR to indicate the end of the previous token as the position for the error, rather than the start of the next token? I understand why the parser sees it this way, but for a person, it can be a little confusing (especially for newbie programmers that might be learning the language). I'm using this in a GUI editor project to given programmers a better tool, so I would like to also deliver a better error message (since the goal is to deliver a better development and learning experience).
I am using a custom IAntlrErrorListener<IToken> implementation to collect the errors for display to the programmer, in case that is important. I'm hoping there is an easy way to perhaps indicate this at a parser rule level, such that the parser can easily be instructed to indicate end of the preceding token as the problem position, rather than the start of the next token.
When you create your listener, you could get a reference to the token stream. From the token the error is reported on you could get the use getTokenIndex() and then you can subtract 1 from that and use the get() method of the token stream to get the previous token.
Note: It probably won’t prove quite so simple as there may be multiple tokens and/or skipped tokens that you have to account for to get to the token you really want to use. So, while you can get to other tokens in the stream it might be “fiddly” to get to the previous token that you want for your error message. (And this is probably getting at why ANTLR gives you the reference that it does)
is there a way to check the written R syntax in .Net? I mean for the case that the user type some R scripts in an editor and the system will tell him before execution that something is wrong in the codes. I have tried using R.Net but it evaluates the code only during the execution process (because it calls the R-Engine immediately).
I think the easiest way would be to use R.NET to either call base::parse and check for errors, or to use a package like lintr for this purpose. The latter one can not only check for syntax errors but also for violations of a given coding style.
These solutions will however be probably too slow for displaying the errors in real time (while the user types). I am not aware of an R parser which is written in .NET.
I'm making an IRC bot in C#, and want to have Lua be executable via a command. I already have this working, and have overcome some basic obstacles, but now I'm having a larger problem with a StackOverflowException; My friend gave me some Lua code to run, which every time seems to cause a StackOverflowException, no matter how hard I try to prevent it.
print(string.find(string.rep("a", 2^20), string.rep(".?", 2^20)))
So, with this being executed using LuaInterface (LuaInterface 2.0.0.16708 to be precise) - I get a StackOverflowException in my code and I don't seem to be able to fix this, looking at some previous questions.
I know parsing code before executing it to predict stack overflows is hard, so I don't know how I would circumvent this. I have already tried multi-threading (which solved a previous problem where yielding code wouldn't return control back to C#) but this does not seem to help.
To get around that particular error use Lua 5.2.2 or newer. The case is a reported bug that got fixed in the version 5.2.2. It gives "pattern too complex" error instead.
And as far as sandboxing is concered why not fashion it after the Lua live demo as suggested in this SO answer? I don't know how secure it is but I'd presume the authors have both the incentive and capability of making it as secure as possible. The sources can be found from here.
We use Acunetix at work to do security scans on our applications. Recently we came across the following Integer Vulnerabilities error below:
From what I can tell, it looks like the report is telling us that we are not stopping integer overflow attacks within querystrings. While we do use querystrings that eventually resolve to integers, they are first encrypted and then decrypted and converted to int using Convert.ToInt32() before we use them. I know that we should use TryParse() instead, but even if a hacker were to enter an integer value higher than max, they would fail when trying to decrypt before even trying to convert to integer, which is where the integer overflow would occur in my opinion. That is unless the error happens when the decryption fails?
I'm pretty confused about this and google searches haven't been much help as most pertain to unmanaged languages like c++ rather than c# and asp.net. Any help would be much appreciated.
I don't think this is an integer overflow vulnerability, I suspect it refers to integers as this is the type that has been manipulated in the querystring (although I know you said they were encrypted). If you're doing a direct conversion of untrusted user input to an integer and not first validating the type (as you say, TryParse it first), you're probably going to throw an internal error (short of any try/catches) and this is what they're likely picking up on.
Automated scanners go a bit nuts over HTTP 500 errors. They don't know what's actually happening under the covers and how severe the error is so you could argue that it's a false-positive. On the other hand, your security folks will argue that websites readily returning HTTP 500 are more likely to be probed further if a bot picks up that you're regularly throwing these errors out as a result of manipulated querystrings.
Easy answer: "All input must be validated against a whitelist of acceptable value ranges." (from here).
In languages that support exception objects (Java, C#), when is it appropriate to use error codes? Is the use of error codes ever appropriate in typical enterprise applications?
Many well-known software systems employ error codes (and a corresponding error code reference). Some examples include operating systems (Windows), databases (Oracle, DB2), and middle-ware products (WebLogic, WebSphere). What benefits do error codes provide? What are the disadvantages to using error codes?
WITHIN a program one should always use exceptions instead of error codes. However, exceptions can't propagate beyond a program. Any time the error must leave the program you are left with error messages or error codes.
For simple things that will always be human-operated error messages without codes are fine. You can say "File not found" without giving it an error code. However, if it might be another computer on the other end then you should give error codes in addition. You don't want to break the other system when you change it to "File <x> not found".
I don't think I've ever used error codes in .Net except in one situation - when I was creating a console application that I knew was going to be called from another app. This other app had to know when the console app failed, and what went wrong. So, one example of when it would be appropriate would be when you know your program will be called by other programs, and you want a structured way for them to understand errors.
That said, I was a newbie to .NET at the time, and have never used error codes since.
As a side note, as a Windows guy, it's nice to be able to plop in an error code and come up with a KB article, so an error code combined with good documentation and the ability to find it = nice feelings from your users.
Very common for web service interfaces. It's very easy and standard to return a code with a description.
I agree that for most of the scenarios is old school
I'd say the biggest disadvantages it's the quality of code. You have to add more complex logic to manage error codes while exceptions are bubbled without having to use method parameters or return values.
You also have to add an "IF" to check if the returned code is SUCCESS or not, while exceptions goes directly to the error handling block.
I'm a newbie to stack overflow but...
I believe that error codes tend to be used or useful for dealing with erroneous situations that require an end-user of sorts to get involved to rectify a situation. If your code is to be maintained by another developer then exceptions is the way to go. However, in a situation where there is a problem:
in the environment that your application is running
with communication between your app and some other entity (web server, database, socket, etc)
that a device or device driver indicates (hardware failure maybe?)
then error codes may make sense. For example, if your app attempted to log into a database on behalf of your end-user, but the DB was unreachable for authentication (DB is off-line, cable is unplugged) then an error code/description combo might help the end-user rectify the problem.
Again at the developer/engineer level who will be able to touch the source code (traditional debugging and testing techniques) and modify it, use exceptions.
Hope this helps...
--jqpdev
I frequently use error codes when an error needs to be conveyed to the user, since they can be internationalized. For example, in a compiler, if there are errors in user code, errors can be signaled in the compiler backend, while the frontend can localize them into culture/language-specific strings for user consumption. Enums may be better for this purpose than raw integers, however.
I've also used them in creating an "error reporting" framework for the app. When exceptions were thrown, they were thrown with an error code, which, when the exception bubbled up, was sent (with a log) to the central server. The code helped organize the database so we could inspect logs related to a specific error.
Finally, as mentioned in a couple other answers, error codes are easy and language-agnostic to google (think Windows error codes/MS KB articles), so an error code with a description of what went wrong may be better for end-users of a technical product.
The idea of error codes is useful, but IMO they belong as exception members or as parameters to an IErrorReporter interface or something more ofthen than as method return values.
Error codes are old-school. They are of little to no value at all.
The only possible value to an error code is that it can identify a very specific circumstance. You could have a code for each point in the code base that can throw an exception. This would allow you to narrow down very precisely what the problem must be.
But nobody cares about that level of detail. Who wants to maintain such a mess. It would leave you with codes that meant something like "condition A and B but not C due to state S". It's more effort than it's worth to try to work out exactly what that means. A stack trace will be more valuable in telling you where in the program the problem occurred.
I learned to program computers before exceptions were a widespread technique. I'm so glad we got exceptions instead!
C#, and probably Java too, supports a better exception handling control flow, the finally keyword, which makes things a little nicer than using error codes. An exception object can contain any level of detail, certainly much more than an error code. So the exception object is way more practical, but you might run into an uncommon case where an error code would be more appropriate.
FWIW, C++ also supports exception objects. I don't think that C++ supports a finally keyword (though the newer C++ whatevers just might), but in C++ you also have to avoid things like returning inside a catch handler.
Error codes were designed in an age where the only way for a function to tell the caller that something went wrong was to assign a special meaning to one or more values of those which can be returned, and very frequently only a native integer or so was available for returning that special value.
For instance, in C the "get character" routine returns the next character value in ASCII, but returns a negative value if for some reason something went wrong. You are then responsible for returning to YOUR caller in a way so this error situation can be handled, and that must return etc.
The Exception mechanism is an elegant way to handle this "this is an emergency, we must return from code until something can deal with the problem". Error codes are inferior to this.
I've written many web services that are consumed by other (remote) applications. When things go badly with a request, customers more or less insist on getting a code, so that they don't have to do some horrific string comparison to find out what went wrong.
Take HTTP result codes as a fine example of this sort of behavior. "200" means happy, "300" could go either way, "400" or "500" means start freaking out.
Error codes are for if you want to send them to the user. If not, use an exception.
Sometimes you don't want to give too much information to the user when an error occurs. For example, a user is not able to sign a new contract. The error message only states something generic like "Cannot sign a new contract".
This adds difficulty to support cases where the user thinks this is not correct. If you have an error code, for example a number or an acronym, it could be part of the error message. The user wouldn't know what it means but the support staff could look it up and could then check if that specific reason for declining the new contract is indeed an error or not.