Error handling with automation variables

Not glamorous, but have your functions return booleans from your automation. If FALSE then ERROR. Or set a global error text variable in your automation and when it gets filled in stop executing. Just a couple ways off the top of my head.

Visual Studio:

public bool Example()
{
   return true;
}

public bool Example2()
{
   return false
}

NAV:

continue = Automation.Example();
IF continue THEN continue = Automation.Example2();

So write your own automation that wraps the dll you want to call.

You can declare the codeunit as a variable, and all of its global variables are going to be available after the codeunit fails. Then in the codeunit, you keep track of the task in a global text variable, let's call it "MyTask". Right before a statement is executed, you set the variable to a message that means something. So in your example, it would be something like this:

MyTask := 'Sending http request';
xmlHttp.send;

If that's where the codeunit fails, the MyTask variable holds the message that you programmed, and you can get to it from where you call the codeunit. All you need to do is add a function to the codeunit that returns the message:

ReturnTaskMsg() : Text[250]
EXIT(MyTask);

And from where you call the codeunit, it goes something like this:

IF NOT MyCodeunit.RUN THEN BEGIN
  MESSAGE(MyCodeunit.ReturnTaskMsg);
END;

It's not really true error handling, but it's a crude way to get there. I used something like that years ago to recover which field validation caused an error.

ta5 wrote:

it's imho not possible to use the "if codeunit.run" construct in the middle of a running transaction

Why not?

So follow the instruction:

ta5 wrote:

Use the COMMIT function to save the changes before this call, or structure the code differently.

It's a puzzle sometimes, but it's usually possible to rewrite the code in such a way that you can use it.

matttrax wrote:

You should avoid using COMMIT unless you absolutely have to

You should use COMMIT when the requirement calls for it, of course you have to know when you can, but there's absolutely nothing wrong with using it.

Simply stating that you should NOT use it is not very helpful :-k