What do you typically put into the Catch part of your Try/Catch?

I’m wondering how others use their Try/Catch blocks, to see if I could improve my methods or am doing something unnecessary.

Here’s what I usually put into them:

  • a Log File activity to output info about the exception to the log
  • a Take Screenshot activity with a Save Image activity, to capture the whole screen for troubleshooting purposes
  • a Throw activity to throw the exception

What I’m mostly wondering about is that last one - using a Throw in the Catch. Does it make sense to do that, or is it redundant? Typically I want the process to stop running if there’s an error. So I use a Throw. Would it be better to use a Terminate Workflow activity?

What I’m thinking is I may be misunderstanding the point to the Throw activity. Is it supposed to be used more for application errors (like when the bot tries to log into a web site but the web site says “invalid password” then I’d use a Throw in order to trigger the Catch).

1 Like

Hello Paul,

What you’re doing mostly makes sense. Obviously the screenshot business is only necessary if you’re using a GUI application and is handled already by the ReFramework so you shouldn’t have to do it manually even if you are.

I usually add both a Log Message and a Throw activity in the Catch that offer more insight into the issue than the standard error message will give.

For instance, let’s say that I was trying to read in an excel sheet, I would put something like:
Log Message: "Unable to open excel workbook due to error: " + exception.Message
Throw System Exception: New Exception(“Unable to open excel workbook”)

I usually make my comments more technically detailed than my actual error messages because I generally let the errors bubble up and present them to the end users. I find that the technical error messages generally stress them out and doesn’t offer any further context than the basic message I give.

In the end, because I have multiple Try/Catch activities that encapsulate things, the end users will get something like: Unable to process item due to error: Unable to open excel sheet.


Good post and explanation! :slight_smile:
Is trycatch and throws the best method of logning errors?

Oh yes, definitely. The standard messages that you get from some of the underlying .net stuff are very vague and usually do not offer any of the necessary context to figure out where and why something went wrong. I have seen error messages like, “The message existed” without any context as to what the message was, what it was expecting, nor why it was bad that it existed.