My problem is if there is an unclosed parenthesis at the end of a document I got the error message: unexpected EOF. This is a bad message and I tried to avoid it.
My grammar has a global backtracking turned on.
Therefore an action is not called until entire rule is matched
and exceptions also are not thrown.
So I cannot use flag in the parser state or an exception handler to rethrow my own to terminate the parser.
Related
I've a grammar that I want to use for both Java and C++ targets. So, I can't use any semantic predicates in the grammar as it eliminates target language independence.
I've something like -
expr : SOME_FUNCTION '(' INT, INT ')'
Now I need to add a check e.g. INT > 2. How do I throw an error from visitExpr() if this condition fails? I see that lexer/parser have error listeners but not the visitor.
Error listeners are used to report errors. By default there's a console listener, which only prints errors to the console. This happens during the parsing (syntactic) phase. By adding an own error listener you can collect the error info into an application structure for later processing.
The semantic phase where you examine the parse tree to determine logical errors comes after the syntactic phase. But still, you can use the mentioned error info structure to receive more errors while you visit the parse tree. No need to throw an exception or something like that. All you do is to collect more errors and store them directly.
Once both phases are done you can then use the error structure to visualize all the errors (red underlining in an editor, showing in an error pane, etc.).
What is the conventional, well-behaved way for a macro to indicate that it's been passed invalid arguments?
(defmacro defthisthing [name & definitions] . . .)
I'm writing a macro right now to accept a whole bunch of definitions. If the same thing gets defined twice, the macro should complain. Similarly, if one of the definitions uses a term that's not defined elsewhere in the same macro invocation, the macro should complain, hopefully with line and column numbers so the programmer can see exactly where the error is.
I'm currently thinking that throwing an exception makes the most sense, because invalid macro arguments are in fact a compilation error. Everything should shut down no differently than if the compiler found unbalanced parentheses.
If that's correct, what is the conventional exception to throw? And how do you include the filename and line number of the offending snippet of code?
And if that's not correct, what is the more Clojurely approach?
Throwing exceptions sounds fine. I just checked the Clojure source and this is how it is done there:
(defmacro let ...) calls (defmacro assert-args ...), which throws exceptions if the arguments don’t meet their requirements.
This question already has answers here:
How to overcome StackOverflowException bypassing unhandled exception handling in .NET
(4 answers)
Closed 8 years ago.
I traverse an array of bytes in a Try...Catch block. Something like this:
Try
For Each curByte In bytes
'Do something with bytes.
Next
Return encodedBytes
Catch e As Exception
'handle exception
End Try
Randomly, my program will crash with an unhandled exception on the Next statement in the code block above. The exception is a StackOverflow in mscorlib.dll "unable to evaluate expression".
Why is my exception handling not handling the exception? I'm not sure I know where to begin trying to address this error.
A StackOverflowException cannot be caught, because it's a fundamentally breaking error that .NET generally can't recover from. That's why you're not catching the exception.
However, its cause is generally quite simple to determine: if you check your debugger at the point where the exception occurs and look at the callstack, you will typically see a recursive call (that is, the same method calling itself in a nested fashion). That's what's causing your exception, and you need to fix whatever logic is calling the recursive calls to address the issue.
In Lua, calling the standard error() function with a message argument outputs the provided error message and also prints stack trace, e.g. executing the following code:
print("hello")
error("oops!")
print("world")
would result in the following output:
$ lua test.lua
hello
lua: test.lua:2: oops!
stack traceback:
[C]: in function 'error'
test.lua:2: in main chunk
[C]: ?
However, calling error() without arguments seems to make Lua die silently without printing stack trace. Executing this code:
print("hello")
error() // no arguments provided
print("world")
would result in this output:
$ lua test2.lua
hello
The documentation doesn't say anything about omitting the first message argument:
error (message [, level])
Terminates the last protected function called and returns message as
the error message. Function error never returns. Usually, error adds
some information about the error position at the beginning of the
message. The level argument specifies how to get the error position.
With level 1 (the default), the error position is where the error
function was called. Level 2 points the error to where the function
that called error was called; and so on. Passing a level 0 avoids the
addition of error position information to the message.
I'm wondering if this is intended behavior or no? IMO it would make sense to still print stack trace (and maybe output some default text e.g. error) even if no message is provided, because that's how the assert() function works.
The documentation doesn't say anything about omitting the first message argument:
Yes, it does, error() has a prototype like this:
error (message [, level])
Notice that only the arguments inside [] is optional, in this case level, otherwise the arguments are mandatory, in this case, message.
Comparing with the prototype of assert():
assert (v [, message])
As you can see, message in assert() is optional.
In some applications, I came across some lines of code which deliberately eats the exceptions. In my application the benefit of doing this is - To ignore the exception and just continue with the loop(The exception handled is for an error thrown inside the loop). The following lines of code looks evil to even an experienced developers. But is sensible to the context(I mean, that is the requirement - to process all the files in the directory).
try{
//some lines of code which might throw exception
}catch(Exception e){
//no code to handle the error thrown
}
What other benefits can ignoring exceptions provide?
If it is a requirement to process all the files, if you get an exception during processing one of them, is not the requirement broken already? Either something failed or the exception is not needed.
If you want to continue the processing handle the exception, then continue. Why not just report the problem with processing a given file,so someone can later process it manually? Probably even stupid cerr << "Hey I had trouble with this file '" << file <<', so I skipped it.\n" would be better than nothing.
Exception is there to signal something. If you are ignoring it either you are doing something nasty, or the exception is not needed.
The only valid reason for ignoring the exception I can think of is when someone throws exceptions at you for no good reason. Then maybe, yeah, ignore.
This is generally the mark of bad code - you always want to handle your exceptions by at a minimum reporting what the exception is. Ignoring exceptions will let your program keep running, but generally exceptions are thrown for a reason and you or the user need to know what that reason is. Doing a catch-all and escaping just means the coder was too lazy to fix whatever problems cropped up.
The exception is if the coder is throwing exceptions merely to pass arguments, which is something I saw on DailyWTF once.
Usually we should not absorb the exception but there can be reason like there is a function which is out of business logic that is just to help some kind of extra functionality, then you do not want your application to break if that function throw the exception in that case you absorb/eat the exception. But I do not recommend the empty catch block, one should log this in ELMAH or other error logging tools for future.
I don't think there any any benefits of ignoring exceptions. It will only cause problems. If you want the code to be executed in the loop, after handling it, it will continue with the loop because exception is handled. You can always process the files in your directory even if you are not doing anything after handling exceptions.
It will be better if you write some log regarding the files for which exception is thrown
If you eat the exception. You may never know what is the actual cause of the problem.
Considerr this example
public class Test {
private int x;
public void someMethod(){
try {
x = 10/0;
} catch (Exception e) {
}
}
public static void main(String[] args) {
Test test = new Test();
test.someMethod();
System.out.println(test.x);
}
}
This will print simply 0 the default value of x as exception occured during division and value was not assigned to x
Here you are supposed to get actual result of the division. Well it will definitely throw an ArithMeticException because we are dividing by zero and we have not written anything in catch block. So if the exception occurs, nothing will be printed and value of x will be 0 always and we can't know whether the division is happend or not. So always handle exceptions properly.