I am trying to make firebug break when an error is detected. Specifically, I have some internal checks in my code, like assertions, that I want firebug to stop on when they fail. I have tried a few different ways and wondered what other people do? Here are the ways I have tried:
Put in some invalid code so that if errors out:
function assert(value) { if(! value) dbgbreak(); } // Fails because dbgbreak not defined
This works somewhat, but does not stop the code in such a way that I can see the stack or examine local variables.
Have it throw an exeption:
function assert(value) { if ! value) throw AssertExecption(); }
This is prettier, but still when I track exceptions I can't see the stack or the locals
Put a breakpoint on the assert failure. This works, however, it means everytime I run my code I have to manually put in a bunch of breakpoints.
What do other people do in terms of working with the debugger and asserts, and similar consistency checks?
Have you tried throwing down the "debugger" keyword in your script where you want it to stop?
On the console tab there is a button for breaking on all errors. Turn that on, and it will automatically break when an error occurs.
http://getfirebug.com/wiki/index.php/Console_Panel#Break_On_All_Errors
Related
Programming for CANalyzer in the Vector CAPL Browser, I can start typing "on message CAN4..." and it will auto complete things for me. I can see the messages. But after selecting a message, it always yells at me with "Expecting message name or identifier. Database missing?" as if it has no idea what I just put in even though it helped me put it there. What is the proper format for this? Is it different since I'm using ARXML instead of DBC? Is it just not compatible?
on message CAN4::Something_PDU // Auto-completes this but gives the error
{
}
on message CAN4.Something_PDU // Never auto-completes this and also doesn't work
{
}
on message CAN4::Something_PDU::Something_Auth // Auto-completes but not sure that's what I want and also doesn't compile with same error.
{
}
What is the right way and/or why doesn't it recognize the database despite its obvious ability to auto-complete? So confused!
I just faced a comparable issue when trying to get called by incoming ethernet signals. They are also defined in an *.arxml, in my case. However, the behavior of the Vector CAPL-Browser was exactly the same as you described.
I figured out that replacing on message with on signal does the trick and the script can get compiled:
on signal Something_Signal // autocompletion works and compiles
{
}
on signal Eth1::Something_Signal // autocompletion doesn't work but compiles
{
}
there is another way to do this: goto Windows symbols on the right panel in CAPL Editor >
try to find Something_PDU > drag and drop PDU_Name on your Code after on message
the CAPL event on message should be use with name
try use
on message Something_PDU
instead of
on message CAN4.Something_PDU
I recently started using the Katalon Studio, for automation. While writing the scripts I checked if an object is present or not on the DOM by using:
if(findTestObject('{Object ID}')){
//do some work
} else{
//do another work
}
if the object is found it's all good, but if it isn't, it continues executing in the else block, but in failure log it shows it as a failure. I've tried implementing some of the solutions to fix it that were on the Katalon discussion page, but none of them worked.
Is there any way to stop counting the else block code into failure?
Recommended way is using Verify Element Present. Try changing your script to:
if(WebUI.verifyElementPresent(findTestObject('{Object ID}'), 5)){
//do some work
} else{
//do another work
}
(in this example, '5' is the timeout you expect to find the element in, lower it if needed).
I believe this happens because findTestObject only returns reference to object in Object Repository but does not guarantee the element is really loaded in DOM.
I have a filter set up as follow to control users login status.
class SecurityFilters {
def filters = {
login(controller:'login|logout|proxy|API|error', action:'*', invert: true) {
before = {
if (!session.isLoggedIn){
switch(controllerName){
case "enroll":
switch(actionName){
...
default:
log.warn "Permission Denied. Default action for enroll."
render(view: '/permissionDenied', model: [message: "You must be logged in to access the enroll system. If you are a consumer, please contact your agent for more information."])
break
}
break
...
}
else {
switch(controllerName){
case "agent":
if (!session.user.isAgent) {
render view: "/permissionDenied", model: [message: 'This portion of the site is only available to agents.']
return false
}
break
....
}// switch
}// else
}// before
...
}// login
}// filters
The problem I am having is that when I run this in development it works fine but when I run it on our QA system it works fine for a while and then suddenly it stops working correctly.
I added logging and I can see that the session information is available in the filter and the session variable (session.user.isAgent) is set correctly (true) but the code inside the if(!session.user.isAgent) gets executed regardless.
I can's seem to find the cause for odd behaviour.
My question is has anyone seen this behaviour before and how did they solve it or have any ideas of where to look for probable cause for the sudden change in the way the filter is working.
Thanks in advance.
UPDATE (02/19/2014):
After adding more logging in an effort to hunt down the cause the filter did not execute the code in the if(!session.user.isAgent) as it was doing before. Now it runs normally and then executes only the render line for when the user is not logged in. The logging still show that the user is logged in and that (s)he is an agent but then it runs the render but not the lines of code above it. It is as if there was a "goto" the render line after it completes checking if the agent is logged in.
Again any information or solution would be appreciated
I've had a few issues with filters and Groovy truth. The problem I was seeing was that no errors were logged, even with aggressive exception catching (i.e. catching Throwable) and the only output in the browser was a blank page. This seems to happen only in Filters- everywhere else the errors get logged.
In my case, the issue was down to Groovy truth. I was trying to set a Boolean attribute on the session, but every time I did this it failed. In the end I had to convert the value to a String, and then set it, and it worked.
I know this isn't a direct answer, but I've been bitten a few times by the above and for example, lazy GString evaluation.
If you're still debugging, I'd log some output showing the underlying Class type of what you think you're dealing with. It may be that when your boolean conditions are evaluated above an exception is being thrown and swallowed. I'd log the actual values of each of your conditional statements to see what they are. Also remove each line one by one, to see if the failure goes away. And/or replace your conditionals with absolute values i.e. true/false to see if the code gets executed. If it does, it points to an error in the current conditional evaluation.
I want to know how i can trace program execution using xcode
I want to know which method being called right now as when you add break point in method
Is there any way to do such alike thing without adding breakpoints??
There are a couple of Debugger-related WWDC 2012 videos, one of which shows you how to add a breakpoint that continues automatically after running a debugger command. This is preferred to adding logging as there is no need to keep doing the write-compile-debug loop.
You can add an action to the breakpoint that calls:
expr (void)NSLog(#"self=%p Method1", self);
Having said that I still use log calls, but I use my own logging framework which prints the name of the class and method automatically (using __FUNCTION__ string generated by the compiler).
after search i found that the easiest solution is to put the following code in your methods:
NSLog(#"<%#:%#:%d>", NSStringFromClass([self class]), NSStringFromSelector(_cmd), __LINE__);
NSLog(#"Check 1 - 2 !");
will show you a log trace ;-)
This is mod_perl2 on Apache 2.2, ActiveState Perl 5.10 for win32.
I override $SIG{__DIE__} and turn on DBI's RaiseError flag, which AFAICT from the docs, should call my override when a database call fails. It seems to almost always, except in one case, and I can't understand why.
My script has an our $page variable, and being mod_perl2, I can get at this from the override like so:
use Carp::Trace;
my $full_trace = Carp::Trace::trace;
$full_trace =~ m/^(ModPerl::ROOT::ModPerl::Registry::.*::)handler .*$/m;
my $page;
if (defined $1)
{
eval '$page = $' . $1 . 'page';
if (defined $page)
{
$json = 1 if defined $$page{json_response};
if (defined $$page{dbh})
{
my $errno = $$page{dbh}->state;
if ($errno ~~ $$page{error_handling}{allowed})
{
# allowed to let it go--no report, expected possible user error at some level that couldn't be caught sooner (usually db level)
my $errmsg = $$page{error_handling}{translation_map}{$errno};
if (defined $errmsg)
{
...
This works fine. Now, within that $page, I have an array ref of 'allowed' error values that I want to do something different with when they come back from the DB. When the DB throws one of these errors, I want to translate it into a user-friendly message, $r->print that in JSON, and stop execution (behaviour A). For some reason, it instead returns control to the script (behaviour B).
Here's the main part of my script:
{
$$page{error_handling}{allowed} = ['22007'];
$$page{json_response}{result} = $page->one_liner("select 'aa'::timestamp");
$$page{json_response}{test} = $$page{error_handling}{state};
}
$page->make_json; # just JSONifies $$page{json_response} and prints it
If I comment out the first line, I get a normal error (handling something unexpected) (behaviour C), which is what I expect, because I haven't added the error that's occurring to the list of allowed errors. What's really strange is, if I cut that first line and paste it into my $SIG{__DIE__} override, it works: the JSON response is overridden, printed, and execution stops before {test} is assigned (behaviour A). Stranger still, I can set {allowed} to any set of numbers, and so long as it contains '22007' in particular, I get behaviour B. If it doesn't, I get behaviour C. Even more strange, I can actually fill my override with anything (warnings, calls to CORE::die, etc.--as long as it compiles) and I get behaviour B still--even though the override no longer contains any of the code that would make it possible! Also I don't get any of the expected results of the calls to warn and CORE::die, just silence in the logs, so I can't even attempt to manually trace the path of execution through my override.
I have restarted Apache2.2 in between every script save. I have even moved the override to the same script file as the script itself, out of the module where it normally is, and commented out the entire module file where the override normally is, and restarted.
If I take out that first line, or take '22007' out of it, I can warn and die and otherwise manually debug all I like, and everything works as expected. What is it about '22007' that it never outputs anything different despite server resets? There are no references to '22007' anywhere else in the entire project, except the translation map, and I can delete it from that file entirely and restart and the result is no different. It's behaving as if it has cached my override from earlier in the day and will never ever forget. It's not a browser cache issue either, because I can add random query strings and the results are no different.
This is the strangest and most frustrating mod_perl2 experience I've ever had, and I've run out of ideas. Does anybody have any hints? The only thing I can think of is that it's a caching problem, yet I've restarted the service countless times.
Since it was the end of the day I thought I would try fully restarting the server computer, and it still didn't change anything. I even, before restarting the server, changed the only line where {state} is assigned to this:
$$page{error_handling}{state} = 'my face'; # $errno;
And yet, the output afterwards had {test} as '22007', which is what it should be only if I had left = $errno intact.
Even if it was, say, the reverse proxy it goes through doing the caching, this situation doesn't make sense to me, since the request can be different. After a full server restart, how can it still be assigning a value that is no longer in the code, i.e., how can it be using my old $SIG{__DIE__} override after a full restart, when it no longer exists in any file?
Update: I also tried changing the allowed errors to '42601' and changing the db call to 'select', which produces that error code, but did not add it to the translation map. It still gives me behaviour B, setting {state} to '42601', so it's not specific to '22007'. Any error code that is put into {allowed}, if that error actually occurs, it's running the old version of the override. Cause an error that's not in {allowed} and it runs the current version. But how does it know whether the current error is in {allowed}, or that that even means anything, before getting to the override? (Because the override is the only place where {allowed} is grepped for the current error.)
This is my temporary workaround, but I would like to solve the mystery and not have to add the extra line everywhere I have a DB call with allowed errors.
package MyModule::ErrorLogging;
sub InsanityWorkaround # duplicates part of $SIG{__DIE__} override for allowed errors
{
my ($page) = #_;
my $r = $$page{r};
my $errno = $$page{error_handling}{state};
if ($errno ~~ $$page{error_handling}{allowed})
{
# allowed to let it go--no report, expected possible user error at some level that couldn't be caught sooner (usually db level)
my $errmsg = $$page{error_handling}{translation_map}{$errno};
if (defined $errmsg)
{
use JSON::XS qw(encode_json);
$$page{json_response} =
{
error => $errmsg,
};
my $response = encode_json($$page{json_response});
$r->content_type("application/json");
$r->print($response);
exit(0);
}
else
{
return 0; # get back to script where {state} can be checked and output can be customized even further
}
}
return;
}
Then my script becomes:
{
$$page{error_handling}{allowed} = ['22007']; # don't be bothered by invalid timestamp error
$$page{json_response}{result} = $page->one_liner("select 'aa'::timestamp");
MyModule::ErrorLogging::InsanityWorkaround($page);
}
This is giving behaviour A.