Halt on condition without error

Jochen_Marquardt · November 4, 2019, 10:53am

Hi,

we start some projects periodically that should process a list of files. If there are no files in this folder at that moment, I receive an error. I tried to integrate the action ‘Halt on condition’ in order to stop the job (as all further actions are not needed in this moment).
It would be a great help to stop a project with the action ‘Halt on condition’ without an error message. The log of the job does not need to show an error in this case.

Regards,

Jochen

andrew.rybka · November 26, 2019, 2:35pm

Hi Jochen,

This seems like a case for the “On condition” mode of the “Derive table” action.

Jochen_Marquardt · November 4, 2019, 9:02am

Could be an option. But for that, it world be necessary to establish the condition in every following derived table. In my scenario, I have about 10 tables. Is that what you meant?

andrew.rybka · November 4, 2019, 9:22am

Can you move all that following tables to a separate module?

This way it will be enough to establish the condition only in one table - the one which will call that separate module.

Jochen_Marquardt · November 4, 2019, 9:32am

Seems to be a good solution. I will try that.

dgudkov · November 4, 2019, 10:56am

That’s exactly a case why we’ve introduced modules

***** moved to #uncategorized

rebmanna · January 24, 2020, 5:31am

Hello,
got a similar problem and it is no longer so easy to outsource everything in one module/SupProject (all parameters must be given …)
An action “Exit on Condition” would be really great.
Just exit without errors and ignore all other actions.
Is something like this planned?

regards,

Adrian

dgudkov · January 27, 2020, 11:04am

Hi Adrian,

I’m not sure if it’s a good idea because EasyMorph does automatic parallelization of workflow branches. E.g. derived tables derived from the same table are executed in parallel. Therefore the calculation order may be indeterminate. In one case, one such derived table can be finished earlier than other, in another case - the other way around. This means that if one branch exits abruptly it may be hard to understand if calculations in other branches are finished or not, which may lead to confusing errors.

The proposed solution is deterministic and clear. Although, I admit, it requires a bit of effort to arrange.

rebmanna · January 27, 2020, 9:38am

Hello Dmitry,

first, thanks for the answer.
To avoid indefinite paths, I therefore very often use the synchronize action.

If I then have reached a defined point, it would make sense to exit/end in some cases.

But ok, I’ll try to redesign the Project.

thanks again,

Adrian