I have built my own error handing in OpenScript osing standard Java
try{
}
catch () {
}
Everything works correctly, It handles exception correctly.
But the problem is that afterwards script does not go to the next iteration, but just calls the public void finish() throws Exception {}
How can I make script go to the next iteration after successfully handling of the exception?
Ok, I found the solution.
The situation is that if OpenScript generates one of its own exceptions (e.g. form is not found), than even if you catch it using standard java syntax, then this execution handling seems to be working, but script does not go to the next iteration.
So, the solution is as follows: (it is actually described in documentation):
beginStep("Trying to execute code, which may go wrong", 0);
// Setting error recovery to warning, so the script will not halt
setErrorRecovery(FormsErrorRecovery.ERR_FORMS_FT_ERROR, ErrorRecoveryAction.Warn);
/*
Some code, which can generate error (e.g. form is not found) needs to go here
*/
// setting error recovery back to Fail, so the script will halt at unexpected error
setErrorRecovery(FormsErrorRecovery.ERR_FORMS_FT_ERROR, ErrorRecoveryAction.Fail);
endStep();
// The hasLastError variable is automatically set to true if there was an error in the previous beginStep() --- endStep() block.
if(!hasLastError()){
/* code goes here to be executed if there was no error */
}
else {
/* code goes here to execute if there was an error */
}
Related
I have a waitForSelector() that fails in 1/5 times due to some target-side JS sometimes loading after 5000ms, which causes Casper to stop operation.
How can I make casper continue operating if a waitForSelector() fails?
waitForSelector takes an onTimeout parameter, which if provided prevents the script from throwing an error.
http://docs.casperjs.org/en/latest/modules/casper.html#waitforselector
You would wrap it in a try catch.
try {
do the code that you need it to do.
}
catch (err) {
optional code if it fails.
}
I am trying to test a workflow where the change i made reordered the deletes and how it cleans up the other indices from hbase.
There are 3 different indices being deleted. The logic somehow roughly resembles this operation.
try{
try{
hTable.delete(firstIndexDeletes);
} catch(IOException ie) {
// clean up and exception handling for first index
}
//more processing logic for second index
try{
hTable.delete(secondIndexDeletes)
} catch(IOException ie) {
// Clean up and exception handling for second index
}
//more processing logic
hTable.delete(thirdIndex);
} catch(IOException ie) {
//Clean up and exception handling for third index
}
I am trying to test the exception handling part via integration tests (i was able to get it tested throughly via unit tests) and i am trying to make the delete thrown an exception and i decided to use a lock on a specific index so that if an delete happens on that row it will throw an exception.
hTable.lockRow(Bytes.toBytes(firstIndexKey));
ideally i expected it to throw an exception for that row when it was deleted as part of firstIndexDeletes but somehow it just doesn't make any difference in my tests, it's not going to the exception handling part like i wanted. Is there something elementary i am missing?
To my knowledge (from routine, close examination of the source) explicit row locks are being retired from HBase. That said I've never tried to use them.
In my opinion, I would expect thorough unit test coverage (where you can exploit mocking) to be sufficient.
I have come across this problem a few times and never been able to resolve it but now I need to solve it once and for all.
I have a procedure which has been throwing runtime errors. This is not a problem as I have an error handler defined at the top of the function and the handler at the bottom something like this:
retryConcat:
On Local Error GoTo concatErr
'Some Code here
Exit Sub
concatErr:
If MsgBox("Could not append the receipt for this transaction to the Receipt viewer logs.", vbExclamation + vbRetryCancel, "Warning - Missing Receipt") = vbRetry Then
err.Clear
GoTo retryConcat
End If
The error handler contains a message box allowing the user to retry if required. Now here is the part which confuses me. The first time an error is thrown it shows the message box and allows the user to retry as expected. The program then jumps to the appropriate line and tries again. However the second time through when the error is thrown it does not jump to the error handler, it jumps out of the procedure and the error handler in the parent catches it instead!
So my question is why does it jump to the parent error handler on subsequent throws. This happens in many places all over my code. In many cases where I can manually check for errors I can stick the code in a while loop to solve it but with runtime errors I am forced to use the error trapping which acts in this rather annoying way.
Any help or advice would be appreciated.
You need ot use Resume retryConcat.
When an error occurs, it jumps into the error handle to concatErr:. You then show the message box, and if the user chooses to retry, the code then jumps to retryConcat. As this you used Goto, it DOES NOT exit the error handler, and so next time the error occurs, it's already in the error handler and has no choice but to raise the error up the chain to the calling procedure.
Using Resume concatRetry allows it to exit the error handler and resume at the required point, meaning next time the error occurs, it can handle is again.
It probably makes it easier to understand, if you imagine the error handler is a state, not a section of code.
I'm running a persistable Workflow in an MVC 3 Application, which is working out well, but when the workflow is completed, a WorkflowApplicationCompletedException is thrown. The Workflow is completed sucessfully, the last actions done and the instance deleted from the database.
I've had no luck searching for an answer so far, so any ideas what is causing the exception would be appreciated. My current workaround is catching the exception and doing my stuff there for the OnCompleted-Event.
I'm simply creating a WorkflowApplication, loading it and resuming the bookmark.
Any hints or suggestions appreciated.
Thanks
application.Load(new Guid(basket.StandardFields.Settings));
application.ResumeBookmark(application.GetBookmarks().First().BookmarkName, WorkflowInputs);
application.PersistableIdle = delegate(WorkflowApplicationIdleEventArgs e)
{
if (e.Bookmarks != null && e.Bookmarks.Count > 0)
{
_viewName = e.Bookmarks[0].BookmarkName;
}
syncContext.OperationCompleted();
return PersistableIdleAction.Unload;
};
application.Completed = delegate (WorkflowApplicationCompletedEventArgs e)
{
CompleteWorkflow(syncContext);
};
application.SynchronizationContext.OperationStarted();
try
{
application.Run();
}
catch(WorkflowApplicationCompletedException)
{
CompleteWorkflow(syncContext);
}
Edit
It seems that the application.ResumeBookmark(bookmark, WorkflowInputs) starts the Workflow and Completes the activities, then when I call run, it complains the it's already completed. But if I don't call run when resume workflow is called, the browser never gets any information and I think it stays waiting endlessly cause not even a refresh can knock it out of the waiting state.
It seems that with ResumeBookmark there is no need to call Run afterwards. I think I was doing it at the wrong place before and so the workflow got messed up, but it seems to be working fine now.
if(hasWorkflow)
application.ResumeBookmark(application.GetBookmarks().First().BookmarkName, WorkflowInputs);
else
application.Run();
MSDN:
Represents the exception that is
thrown when an operation on a workflow
instance is not valid because the
instance has completed.
The code you show appears valid. However, somewhere you are attempting to resume a workflow that has entered the completed state. You should be checking the Completed property of any Workflow you are attempting to resume. Thrown an InvalidOperationException and you'll see where this is happening.
If this doesn't identify where the problem is, your workflow may not be bookmarking properly. That code is in the activity that is creating the bookmark, so I can't tell if it is being done correctly...
I frequently encounter this situation in my VB6 applications
Private Sub DoSomething
On Error Goto err1
Call ProcessLargeBatch1
Call ProcessLargeBatch2
'... more ...'
Exit Sub
err1:
Call Cleanup 'Specific for DoSomething'
Call HandleError 'General error handling: Logging, message box, ...'
End Sub
The Cleanup procedure sometimes reverts actions, rolls back a transaction, deletes temporary files, and so on. In most cases this operation can also fail.
What do I do in this case? I'd add an On Error Resume Next into the error handler but that deletes the existing Err object. Adding an error handler to Cleanup has the same problem.
What is the best way to ensure that the original errors still gets processed/logged?
EDIT: One additional problem is that I also want to notify the user of the error. Sometimes it is important, that the cleanup happens fast and I don't want the message box block the application for a long time and do the cleanup after the user acknowledges the error.
Firstly, read all the information out of the Err object that you will need, i.e. number, description, etc., then clear the error and do what you want.
Change the way you inform the user to use the values you have cached, and not to use the Err object itself.
From your example you are doing the cleanup properly. Your HandleError should only log the error not do any UI. The UI is handled up at the form level.
What you need to when an error occurs is
Clean Up
Log the Error
Raise the Error Again via Err.Raise
This will work it's way up the call stack to the event that called the original code. Then the sequence will become
Clean Up
Log the Error
Display the the Error Notification Dialog
Note that your Error Logging can be intelligent in that subsequent logs of the same error can just add to the recorded call stack.
You want to make sure that EVERY event has a error handler. Not every procedures needs one but definitely every event. Unhandled errors in a event will cause a VB6 application to shut down unexpectedly.
If I can handle all errors in one place, I'll usually put in into a structure something like this:
Public Sub SubThatShouldHandleErrors()
Const ROUTINE_NAME = "SubThatShouldHandleErrors"
On Error Goto Catch
' "normal" processing here...
Finally:
' non-error case falls through to here
' perform clean-up that must happen even when an error occurred
On Error Goto 0 ' reset: not really needed any more, but it makes me feel more comfortable
Exit Sub
Catch:
' Error handling here, I may have logging that uses ROUTINE_NAME
Resume Finally
End Sub
If I need more than one error-handler, I'll try very hard to restructure my code to make that not be the case but if absolutely necessary I'll write a custom handler; my template is only a guideline.
Log your error first. Then do an On Error Resume Next. Have your cleanup encapsulated in methods that have their own error handling. This should be yourbest bet.
I really really don't like error handlers. This is what I do;
Create a Error class or module that contains all properties that the built in one contains, as well as a CopyError-method that fills these properties from the err-object.
Watch for errors where they can appear:
.
' lots of code that will probably work
On Error Resume Next
Open "c:\filethatdoesntexist.txt" For Input As #1
Error.CopyError
On Error Goto 0
Select Case Error.Number
Case 53'File doesn't exist
' handle that error here
Case 0
' no error
Case Else
' Just throw the error on
Err.Raise Error.Number, Error.Description, ...
End Select
' more code that will probably work