In a robot in Studio I have a Do While loop, including a Get IMAP Mail Messages (GIMM) activity that checks whether new mail has arrived from a specific email address. It often happens that the robot gets stuck here because, for example, no connection can be made with the IMAP Server. I have already increased the TimeOut in the GIMM activity and I have placed the GIMM activity in a Try Catch activity with 2 exceptions: System.Exception and System.TimeoutException. Still, the robot keeps getting stuck. I then get (for example) the message: Try Catch: The IMAP server has unexpectedly disconnected.
I have now found a (partial) solution:
Assign: boolIMAP = False
Retry Scope (5 retries with an interval of 5 seconds).
Action: GIMM and Assign: boolIMAP = True
Condition: Check True: is boolIMAP True?
With 5 retries it should usually work fine, but of course it can happen that the robot also gets stuck after 5 retries. In that case the robot should actually continue in the Do While Loop. For this I could put the Retry Scope activity in a Try Catch activity. Since initially System.Exception and System.TimeoutException did not work, I wonder which exception I should use in this case?
If you have the solution for me, you are my hero of today!!
Thanks in advance!
To handle the case where your Get IMAP Mail Messages (GIMM) activity may cause exceptions not caught by your initial Try-Catch block, you can try using a more generic approach to catch specific exceptions that are common when working with email servers.
Since you’ve already tried catching System.Exception and System.TimeoutException and it didn’t prevent the robot from getting stuck, it’s likely that there are other relevant exceptions that need to be accounted for.
Here are a few steps for improving your solution:
Use a Broader Exception: In the Retry Scope that you use for your GIMM activity, consider catching System.Net.WebException. This type of exception is often raised when there are issues connecting to network resources, such as an IMAP server.
Increase Resilience: You can combine the Retry Scope with a Try-Catch around it. In this configuration, the Retry Scope will attempt its retries, and if it still fails after the limit, you can catch the exception in the Try-Catch block and allow the workflow to continue.
Here’s a suggested approach:
Retry Scope: Set the Retry Scope with several retries as you have already. If it fails, you catch the exception.
Try-Catch: Wrap the Retry Scope inside a Try-Catch block. In the Catch section, you can log the exception, but the processing can continue.
Here’s an example structure:
Do While
Try
Retry Scope (5 retries with an interval of 5 seconds)
Action: GIMM
Assign: boolIMAP = True
End Retry Scope
Catch System.Net.WebException
// Handle connection-related issues and log
Assign: boolIMAP = False
// Optionally, log this exception
Catch Exception
// Handle any other exceptions
Assign: boolIMAP = False
// Log the exception
End Try
// Check if boolIMAP is True and continue processing otherwise
If boolIMAP Then
// Continue processing
End If
End Do While
Key Points:
Logging: Always log exceptions to have visibility into what went wrong, especially when your retry logic is exhausted.
Conditionally Continue: After the retries, if boolIMAP is False, the loop will proceed without getting stuck.
Additional Exception Types: Depending on the library you are using or any specific behaviors you encounter, you may wish to include other exception types specific to imap connections or logging in.
By implementing this structure, you should find that your robot can handle those unexpected disconnections or timeout scenarios much more gracefully.
