Token taking priority over everything - javacc

I have defined a token <ALL: (~[])>, to use to catch if all other options in a (x|y) statement fail.
That have yet to employ it anywhere, but whenever I run the program, it gives this error
How do I fix this?

Related

Robot Framework - Keyword to do in case the leadtime is not respected

I'm stuck on something in my Robot Framework project. When I hit a button from the 1st page after the login is done, another tab is opened, however, sometimes, the new window is not loaded and the code (robotframework) keep waiting for an answer.
To avoid getting an error when this situation happens, I want to solve it while the code still running, I want to know if there is any keyword that applies an action in case something is not done within a given lead time. In my case it would be to close the new window and repeat the previous step (hit the button from the first page again), therefore, it would be 2 actions in case the actions fails (lead time).
I have tried to use the keyword Run Keyword and Return Status, in my case the status would be false, however, since my code is kept waiting for an answer, the status is always True, therefore, it does not work for me.
I have read that there is a keyword named Run Keyword If Timeout Occurred however, it can be only used on Teardown`, therefore, I also don't know if it can applied.
I see you are trying to compare Boolean and String.
it's should be boolean and boolean run Keyword if ${status}==False.

How to force sign out user if firebase.app().auth().signOut() return error?

How to force sign out user if firebase.app().auth().signOut() return error ?
firebase.app().auth().signOut()
.then(() => console.log("good"))
.catch(() => {
/*I still need to sign out user*/
});
It is very unlikely you get an error in that case as this operation simply clears the state from local storage (localStorage, indexedDB, sessionStorage). The only possible error could be related to that (access to these local storages fails for some reason which is rare if you already were able to write to them). It would be better to show the error to the end user so they can take some other action such as clearing their cookies for the site, etc, especially if the user is using some shared device.
It is probably best to display an error to the user saying that they were not logged out and they should try again.
Or, you could put this logout call in a function, and then call the enclosing function in the catch field, although if an error keeps occurring it will be stuck in an endless loop, so I would advise against.
If an error is occurring, clearly something is not right and they are not being signed out for a reason so it may be worth handling specific logout errors instead of trying to "force logout".

Why does execve() does not return on success?

I have read the man pages.
All I understood from this link http://support.sas.com/documentation/onlinedoc/sasc/doc750/html/lr2/zid-7281.htm is that
A successful call to execve does not have a return value because the new process image overlays the calling process image
I am not very clear as to why this will happen ? And if the new process overlays the calling process, why does it return on failure only and not on success ?
Because if it fails to do what it is trying to do, i.e. replace the process with the new one, then it makes sense to return, to inform the caller that it failed.
If it succeeds, then the code that called execve() is no longer present, it has been replaced by the successful execution of that function, so obviously it cannot do anything any more. Returning is such a thing.

Meteor: The Loop of Death

I have noticed something really embarrassing with Meteor. When an error occurs inside a method on the server, this makes the entire code of the method to be rerun. This can lead to some unexpected results and some kind of trouble. For instance:
Meteor.methods
'someMethod': ->
# we insert an element in the database
Collection.insert({ record: "We want this record to be inserted only once." })
# We just made a mistake here, let's say that the object is not defined.
variable = object.property
return variable
What happened in my case is that Meteor throws an error saying that it cannot read the property of undefined (I can see it within the server logs) and then rerun the code of the method repeatedly throwing the same error again. I can see a lot of records inserted on my database when it should have one.
I don't know if there is a way to ask meteor to not rerun the code when an error occurs or some kind of thinking I need to learn while developing an application with it.

Why does array_map throw a warning when the closure raises an exception?

I've recently started programming with PHP again, after a long stint with other languages during which i've developed a more functional style - which i'm hoping to try and maintain.
I've noticed some weird behaviour, which I managed to distill into a testcase that I'm hoping someone can explain.
$func = function($item) {
if ($item == 0)
throw new Exception("Can't do 0");
return $item;
};
try {
array_map($func, array(1, 2, 3, 0, 5));
} catch (Exception $ex) {
echo "Couldn't map array";
}
When executing the above code, i see the following output:
Warning: array_map(): An error occurred while invoking the map callback in map_closure.php on line 10
Couldn't map array
I can suppress the error with # on array_map, but this seems hacky at best.
The warning is generated because, put simply, the callback function is not returning normally (due to throwing the Exception). This is just the way that array_map() is coded, if the callback function does not complete its execution. Remember an Exception breaks out of execution immediately, as far as your PHP code is concerned.
As for how to silence the warning, that's entirely up to you. Unfortunately, the warning will be generated and it's your choice to bury it or let it get displayed.
As an aside, maybe your test case was over-simplified but, it would make much more sense to use array_filter() (or perhaps array_reduce()) there.
As preinhaimer says, array_map makes it really hard for you to see exactly what happened during its execution because it predates exceptions. It would not be practical to change its behavior anymore since that would lead to lots of (poorly-coded) applications breaking; that's life.
If you want a mechanism with which to check if the array_map completed without errors or not, I have posted a detailed answer (with code) to this question which deals with practically the same problem. It's not as easy as try/catch, but you work with what you have.
Either use # or a foreach instead of array_map
array_map() predates exceptions so it still uses warnings. There's a few annoying places in PHP where you're still forced to use error handling, this is one of them.
You're left with options like having it return null or some other un-used value when it encounters a problem, or filtering the array to ensure it only contains valid options before you run it through array_map.

Resources