Best Pratices in code stage

[EmersonF]

Hey guys, how are you? I hope you are well, I came to open a discussion about the best practices when using the code stage, I encourage you if you have any practices that you want to share, feel free.

I usually always place my codes inside blocks with Try Cath returning a flag and a message, in case of success the flag goes out as true and the message is empty, in case of error I set the flag as false and catch the exception message inside mine viable message.

Right below the code stage I validate my execution through a decision, if everything went well with my execution he should finish the action without problems, otherwise he will launch a Throw with the detail of my error.

And Fluxo of the action.

#BPTechTips
------------------------------
Emerson Ferreira
Sr Business Analyst
Avanade Brasil
+55081988869544
------------------------------
​

[bruce.liu]

Hi Emerson,

I am offering my two cents here. It is said Try Catch block is a good practice in any programming and it largely applies to Blue Prism too. However there are a few scenarios where I think Try Catch is not entirely necessary:

1. You are not expecting any specific output as a result of the code stage executing.
2. You do not wish to customise the error message upon exception.

In your example, it is arguable that if Try Catch is a must-have. You can very much achieve the same outcome without using Success variable. Blue Prism by design will throw an error and float the exception message even if you do not explicitly catch it.

------------------------------
Bruce Liu
Senior Product Consultant, Professional Services
Blue Prism
Australia/Sydney
------------------------------

[swolonda]

Hello guys,
my programming skills are not high and we actually don't have any "code expert" in our RPA team.

So from my point of view the best practice number one is this:
Keep people away from your code (including yourself)!
Make the code stage as simple as possible, Prepare input for the code stage ahead via some calculation stages (string modifications, enumerators etc.).
It might be even a good idea to put some brief summary of the code into some note "stage".
That way you reduce the number of developers who care about the inside of the code stage. 


Regarding the Try-Catch blocks: I almost never use them, precisely for the reason n. 2, that Bruce mentioned. I usually find the standard system error messages more helpful than the customised ones. 

------------------------------
Stanislava Tlustá
------------------------------

[EmersonF]

Thanks @Bruce Liu and @StanislavaTlust for the collaborations, I will certainly take into consideration when you need to write a code again.​​​

------------------------------
Emerson Ferreira
Sr Business Analyst
Avanade Brasil
+55081988869544
------------------------------

[AndreyKudinov]

You don't want to use try-catch in code stage if you expect it to just always work, yet it might still fail for some unexpected reason (SAP is down!?), which you can't handle anyway and might as well just terminate at that point.
Then you'd have to wrap that code stage with a success check that is useless 99.99% of the time. On the other hand, if you dont do try-catch, you can either just let process terminate or use except-resume when you actually expect it to fail and not waste execution time on evaluating sucess status every time.

In fact, I'd mostly use try-catch only if I can handle it within code stage itself or it is expected to fail often and it is easier to customize error message there.

------------------------------
Andrey Kudinov
Project Manager
MobileTelesystems PJSC
Europe/Moscow
------------------------------