How can i clear previous error log in Testcomplete
as the object is visible after some time. I am using Do until loop to wait and get the object, the error is logged when the object is not visible.
But the object is visible after some time loop is ran. Can i clear the previous error logs, or do i have any other solution for it. Please help...
Thanks
You might want to use the objects Exists property as it does not throw error messages (afaik). A quick draft (untested):
while not Aliases.Device.Mapped.Name.Of.Object.Exists
' Wait
wend
Related
In my application,I am using Session_OnEnd event on global.asa file to log the logged out user details to one of my table. For that I am creating an object of one of my VB component from Session_OnEnd event and from there I am inserting into one of my table.
In certain scenarios (Multiple user’s session end happens at a time), we are getting an Unhandled exception while creating above object, since my 1st request is already in processing status.
Anybody of you suggest any good method to overcome this issue?
Dim objClean
Set objClean= Server.CreateObject("Clean.clsClean")
Call objClean.Cleanup(Session, Application)
Set objClean= Nothing
Set objClean= Server.CreateObject("Clean.clsClean") this line is throwing an exception in my case.
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...
In VB6, I have the following line of code in the Form_Load event:
DOSOMETHING()
MsgBox "Done"
DOSOMETHING() is a buggy function that I expect to always crash. When I run the app, it will do its thing and crash, without showing the MsgBox.
But when I write it using loops:
Dim X as Integer
For X = 0 to 1000
DOSOMETHING()
MsgBox "Done"
Next X
The application will not crash, ever. I thought that this has something to do with delays, so I also tried to add a SLEEP inside the loop, to no avail.
So my question is, Is there a special "On Error Resume Next" inside a For loop in VB6?
PS:
If anyone is curious about why I'm asking this, I am trying to reproduce an intermittent bug by calling the function multiple times. Said function is used to check for Administrator function. More detail about the function here.
Thanks!
I't might have something to do with the fact it's called from Form_Load. Perhaps some initialization later in Form_Load or in Form_Activate causes it not to crash.
Try inserting DoEvents after the call to DoSomething. This yields to the o/s, allowing events in its queue to be processed and may enable the function to complete, or fail! before returning to its calling parent.
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