How to use Throw and ReThrow

Can anybody please explain when and how to use Throw and Rethrow activities?

What I need to do is catch an exception with a try-catch - BUT - I need to report the actual exception and then pass control up to a higher level - essentially: catch an exception - log what happened and abort the current process and restart at the top.

Can Throw and Rethrow do this - how? what is the difference between the two?

Update - OK - Rethrow is clear enough it just reproduces the original exception

But how do I use throw to CREATE an exception?

AND - in a try-catch - how do I get the value and information of the exception?


In Throw activity you can specify type of exception you want to throw and message. In try-catch activity you can catch specific exception and get message using Message property.


Fine … but how do I create an exception with throw - how do I populate the exception object???

More importantly - how do I get the information of the exception that I caught with the trycatch???


@bdavidov Try this example

simple_try_catch.xaml (5,3 KB)


To throw an exception in the ‘Throw’ activity you would use the following syntax

new Exception("Throwing an exception because something went wrong")
new BusinessRuleException("Throwing an exception because this transaction needs to be referred back to the business")

In the ‘Catch’ activity you can choose the type of exception you want to catch and then to get the message you would use exception.Message (if you just want the message) or exception.ToString (if you want the message and the full trace)


Thank You!


Andrew’s reply was good.

Just wanted to add that the “Throw” activity is only useful if you want to simulate an Exception like in an If condition or something which will end the process or enter the Catch. The “Rethrow” acitivity is useful if you want activities to occur before the Exception is thrown, so in the Catch you would put that activity and it will throw the Exception that occurred originally that put you into the Catch and end the process.

If you are wanting to continue with your process then simply just use the Log message in the Catch and let it continue.



I found this useful link explaining the dos and don’ts of exception handling. These apply fairly well to UiPath, with one caveat: in unattended workflows there is of course no user to take note of an exception dialog and perform steps to get back to what he was doing. In these cases you should at the least handle all exceptions at the main workflow level and do things like retrying some (perhaps alternative) steps, taking a screenshot of the desktop and mailing it, logging the exception, and/or reporting the current Transaction as failed to Orchestrator with an Application or Business error status.


@sfranzen, thanks. That’s useful stuff indeed.

1 Like

do you have any sample example of xaml?

1 Like

Thank you all … I now am using throw and rethrow effecftively.

Here is the key missing information that I needed and that uipath fails to document:

when an exception occurs uipath creates an “exception” object named: exception.

The exception object has many attributes such Message - which is the actual message text.

rethrow takes an existing exception and regenerates it - so that it can be caught by a higher level try-catch - or not - meaning it will stop the robot and display the exception.

Throw is for generating your own exception - and the KEY piece of missing information is that you must first instantiate a new object of type object and populate the Message attribute or other attributes.

Can somebody - anybody please explain to me why this is not Documented by uipath??? Or if it is - please send me a reference :


Most of what you’re asking here is covered in the academy lesson 12 (I don’t think Throw is though). At least to a level where you should be able to understand how to use it in most cases, not necessarily how it works.

There’s IMHO 2 reasons why for these parts UiPath doesn’t go too deep, which are themselves a Catch-22:

  1. It’s already documented for .Net and Workflow Foundation by Microsoft, so it’s redundant. But if you’re not a programmer, you might have a hard time reading into it or even finding it.
  2. If they do document it, it’s redundant and either the documentation will be worthless for the most part (don’t go deep) or it will repeat what’s already on MSDN.

There’s no easy solution to that, as the audience for UiPath is very broad - from very technical to business people. You can’t satisfy all.

Some small corrections though:

Exception is created by the code that was trying to execute and failed. The “exception” object in the Catch clause is an object where exception data is stored once it bubbles up to that point. Btw - you can change the name as you please.

Not exactly. Rethrow let’s the exception pass further up - it’s still exactly the same exception (this is a key difference between using Rethrow and Throw(oldException) ).

You probably know that, but for potential other readers - object created needs to be of type Exception or any of the derived types (ArgumentException, BusinessRuleException).

And that’s the thing - you can dive as deep as you want with this, question is how for is it actually worth it, since it’s already there by other parties (MSDN and programmer sites). It’s an unfortunate reality for non-programmers - sooner or later you will need to start using programming knowledge (you already are if you’re using UiPath, even if you don’t realise it) or you will hit a usefulness ceiling.


Indeed, all programmers do in the end is come up with algorithms to automate tasks or solve problems. UiPath just allows you to “program” at the level of application interfaces, almost without the direct use of the underlying programming language. But in the end, your workflows are compiled and executed just like hand-written code.

As Andrzej says, it is hard to provide the right level of training for every individual learning UiPath. However, I do think there could be value in some extra courses about the basic programming concepts that relate to UiPath; topics like objects, instantiation, methods, operators. The definitive documentation is of course MSDN, but I feel it would help a great deal to give people some background about what the tutorials make them type. Like: myString.Trim, myString.Replace(...) are invocations of methods of the String class on the instance myString; Message is a String property of the Exception class. This is easy to read if you understand the jargon and rather a mouthful of buzzwords if you don’t. Having some understanding will allow you to search and interpret results more effectively.

My own history is that I learned programming, though not in VB or other .NET languages, before UiPath. It is my experience that I can often answer questions fielded here by applying just my conceptual knowledge to find the right documentation and interpret its technical terms and examples. While this often leaves people with a solution, the questions are frequently very specific: a user wants some steps to solve a particular problem in the workflow he/she is developing. This is of course fine, but sometimes the best solution is an improved insight into the programming concepts behind it, which you don’t always get this way.

Therefore I compliment you for asking about this very important concept in programming. :grinning: What you have just discovered is also why it is difficult to document some things in full detail: instantiating objects is the core business in object-oriented languages and it permeates everywhere. Exceptions are just objects like any other; nothing special happens until one appears in a Throw statement.


Hi all,

Can we Execute UiPath Process by using application program interface?

1 Like

Only if you have your Robots connected to Orchestrator.


Thank you, Ovi.

1 Like

Please find below attachment,
Main.xaml (10.5 KB)



@ClaytonM please post a workflow to explain your post.


Hi @danesh,

Check out the post right above here:

The Exception you use in the Throw depends on what you are looking to throw. In his example, he is using a FileNotFound exception, but you can use others. And, if needed, you can also place a Rethrow in the Catch and it will throw the exception that had occurred. (to be honest, I use Rethrows temporarily more for troubleshooting than actually a part of my code; it’s a good way to pause and figure out what errors are happening, although you can also use a Message Box with the below information and is just as good)


The functionality of Throw is clarified. Could anyone please elaborate a scenario differentiating where Rethrow can be used and how it differs from Throw. The statement “activities are occurred before exception” is a bit confusing. what is it exactly meant by. Can anyone share the knowledge explaining through examples how throw and rethrow are differentiated??