Error handling with automation variables

ta5

Hi

When using automation variables in NAV, it's sometimes quite hard or even impossible to avoid errors.
For example xmlHttp.send: If the endpoint is not available, an error occurs.

Sometimes it's possible to pack the critial code in a kind of wrapper codeunit and call this codeunit with "if codeunit.run". If the result is false, we can then handle the error or at least stop the current code execution in grace. But this approach is not possible if a transaction has already begun.

Do you have made same experience, or even better have a solution for that? I guess, one solution would be to program a wrapper class in c# or vb.net that sends back a status to NAV instead of raising an error.

May thanks in advance
Thomas

matttrax

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.

ta5

matttrax wrote:

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.

Hi Mattrax
Thanks a lot. What do you mean with "have your functions return booleans"? Can you show some sample code? My problem is, that I cant avoid the automation object to throw an error. :?

Thanks in advance
Thomas

matttrax

Visual Studio:

public bool Example()
{
   return true;
}

public bool Example2()
{
   return false
}

NAV:

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

ta5

Thanks, but this means its your automation object. If you use a standard object like msxml6 (for example send method of xmlhttp) then this object throws an error if the endpoint is not available. Do you agree?

Thanks
Thomas

matttrax

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

ta5

ta5 wrote:

I guess, one solution would be to program a wrapper class in c# or vb.net that sends back a status to NAV instead of raising an error.

Thanks Mattrax, this was also my initial input. I was searching for a solution without visual studio.
Regards
Thomas

DenSter

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

Thanks Daniel, I also use this approach sometimes. But the big problem is with transaction, it's imho not possible to use the "if codeunit.run" construct in the middle of a running transaction.
Thomas

DenSter

ta5 wrote:

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

Why not?

ta5

When using the "if codeunit.run" construct in the middle of a trx the following error is thrown:

The following C/AL functions can be used only to a limited degree during write transactions (because one or more tables will be locked).
Form.RunModal() is not allowed in write transactions.
CodeUnit.Run() is allowed in write transactions only if the return value is not used. For example, 'OK := CodeUnit.Run()' is not allowed.
Report.RunModal() is allowed in write transactions only if 'RequestForm = FALSE'. For example, 'Report.RunModal(...,FALSE)' is allowed.
DataPort.RunModal() is allowed in write transactions only if 'RequestForm = FALSE'. For example, 'DataPort.RunModal(...,FALSE)' is allowed.
Use the COMMIT function to save the changes before this call, or structure the code differently.

DenSter

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

You should avoid using COMMIT unless you absolutely have to. Don't want to be writing your own rollback routines.

DenSter

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

matttrax

I don't mean you should never use it...just that you should be extra careful when you do. It of course has its proper uses and should be used when the situation calls for it.

ta5

Yes, good old commit command..
Any other input concerning the error handling?

Many thanks
Thomas