In opera dragonfly, we have 2 button:
Break on first statement of a new script
pauses the execution each time a new script is loaded and the first statement is evaluated.
Break on error, but in dragonfly it's called "Show parse errors and break on exceptions"
Description:
It is possible to get Opera Dragonfly to stop execution when a parse error occurs. Enabling the last button in the Scripts toolbar will stop JavaScript execution at the line where the parse error occurred and highlight it in the gutter in a similar manner to breakpoints. The same button will also stop execution when an exception is thrown.
What is it the second break "Show parse errors and break on exceptions" ?
When I load gmail page it will stop execution. It's the same like pause on all exceptions?
Thanks.
yes. Break on error simply pauses execution when exception is thrown or script cannot be parsed, this is quite handy.
but an anyway, you kinda already answered your own question.
Related
I'm trying to open a page (target: /selenium#/login), but I keep getting a timeout error. The page seems to be done loading so I don't get why I keep getting the error. Also, the error only occurs when I'm playing the entire test suite. When I try to run each test case individually, the error doesn't appear.
EDIT: Forgot to mention, the error doesn't occur when I open a new tab right before the next test case starts (before the open command is read), so each test case has to be on an entirely new tab/window. Here's a screenshot: http://i.imgur.com/pF2e6iU.png
I've run into an issue with the automation of one of my Photoshop scripts where it can be completely halted by an error in a supporting action set. The script does about 99% of the work, but the remaining 1% has to be done in an action due to the work being done (the work is NOT scriptable, or at least not efficient in the least to put to script). The problem I'm running into is that, if there is an error in the layer name in the action, Photoshop pops up an alert about the issue, halting the whole process until I click the "Ok" button on said alert.
Is there any way to catch these errors (a simple try/catch on the action activation code doesn't work), or at least suppress the errors so they don't halt the entire process? Thanks in advance for any help!
Edit: Correction on the error type; it's not an "Ok" alert, it's a "Continue/Stop" alert. The message accompanying it is "The object "layer "layerName"" is not currently available". This happens if the person creating the action failed to rename the layer before performing their work on it and halts the entire automation process until I click continue or stop.
You should convert the action to a script using ActionToJavascript.jsx. After which you can then modify the script to look out for errors - such as you mentioned with the layers not being named correctly.
In Chrome dev tools we can use the 'Pause' icon on the bottom row of the interface to break on all exceptions. So when our web page is running, we can break it suddenly without adding breakpoint and know where the script stop.
Can we do that in opera dragonfly?
Thanks.
There's a "Show parse errors and break on exceptions" toggle (immediately left of the drop-down selecting what script to show currently).
I was working on a Windows app today, when my errors were no longer being displayed as they usually would. Instead, the debugger just jumps out of the method. The output window makes a note of the exception, but the usual popup trace does not appear.
It works in other projects, and I have put Dim i as Integer = "A" as my first line to try and raise an error, but it just exits the sub on that line.
Any ideas how I get it back?
There is a bug in the interaction between the debugger and the 64-bit version of Windows 7 that strikes in the Load event. An exception is trapped and swallowed by Windows, the debugger never gets a chance to detect that it was unhandled. The only thing you'll see is a "first chance" notification in the Output window. The Load event handler will immediately terminate and your program keeps running as though nothing happened, assuming that it didn't bypass a critical piece of initialization code. This bug has been around for a long time and is well known to Microsoft, apparently it is difficult to fix.
You can work around this bug with Project + Properties, Compile tab, scroll down, Advanced Compile Options button. Change the Target CPU setting to "AnyCPU". Another way to trap it is with Debug + Exceptions, tick the Thrown checkbox on CLR Exceptions. Yet another workaround is to put initialization code in the constructor instead of OnLoad() or the Load event. You only really need Load when you need to know the actual size of the window.
This bug will only strike when you debug. It won't happen on your user's machine.
UPDATE: I expanded a great deal on this mishap in this post.
Under the Debug->Exceptions check that the Common Language Runtime exceptions are checked.
Has your .suo file been deleted by any chance (this is the file that stores your personal state of the solution, your settings, what is expanded / collapsed). You will only really spot this if you suddenly noticed that you had to hit "collapse all" because it had forgotten, it will recreate this when you open the solution, but will do it with default settings.
If so, hit CTRL + ALT + E and re-tick the break on exceptions tick boxes for CLR exceptions.
When an exception is thrown in my app, I expect the debugger to stop running and enter debugging mode, but it does not. Instead, I just get a message in the Immediate Window ('A first chance exception ...'), and the program keeps on running like if nothing happened. However, the sub (in which the exception was thrown) is exited, so statements after the exception are not executed. Since this sub makes the initialization of my program, running becomes very unstable.
How can I tell the debugger to stop execution when an exception is thrown?
(I use VB 2010, and did not change any setting of the debugger.)
UPDATE:
Thanks for the quick answer. Unfortunately, I still can't get it the way I'd like.
On the 'Advenced compile options' page I don't have 'Target CPU'. Maybe it's that I have only VB Express?
If I tick the 'Thrown' checkbox in Debug > Exceptions, execution stops even if I have a catch for that exception, and I don't want that.
Until now I used VB 2008 on 32 bit, and everything worked fine, but since I moved to 2010 64 bit I just can't get it right. Any suggestions?
Debug + Exceptions, tick the Thrown checkbox for "Common Language Runtime Exceptions". The debugger will now stop on the first chance notification.
The usual cause is a catch statement in your code, maybe the VB.NET On Error statement. Or a bug in the 64-bit debugger's interaction with Windows Forms. After it breaks, use Debug + Windows + Call stack and check if the form's Load event handler is on the call stack. The bug causes unhandled exceptions to be swallowed without a diagnostic.
To work around that, use Project + Properties, Compile tab, scroll down, Advanced Compile Options. Change the Target CPU setting to "x86". This is the default setting for VS2010 projects btw. You'll now use the 32-bit debugger, it doesn't have this problem. And you can use Edit + Continue.
I know this is an old thread but I hope it may help others..
I was facing a very similar problem at startup of my forms.
I put my code in "shown event", instead of "load event" and it is SOLVED !
I mean I get exceptions as expected, and my codes do not exit silently.
I know they are different events but for me it didn't make any change.
BTW, my env: VB.net Express 2010 on Win7 64 bit
To get the Target CPU option you must have expert settings selected in VS2010 express. Go to Tool|Options and check expert settings.