New function ASSERTERROR

Belias

hi everyone, i noticed that there's this new function:
http://msdn.microsoft.com/en-us/library/ee414211.aspx
i was wondering if someone of you have an idea on how to use this function (except for testing).
In other words...how can it be used "improperly" to skip errors (maybe this function can replace the "IF Codeunit.run then begin" construct)?

Slawek_Guzek

Belias wrote:

...In other words...how can it be used "improperly" to skip errors (maybe this function can replace the "IF Codeunit.run then begin" construct)?

It probably can be used 'improperly' to catch the errors.

Imagine you try to SETFILTER(integerfield, UserInput) in your code, and user put '100*' in UserInput field. This will give you error message. Checking UserInput syntax before SETFILTER is possible but quite hard to do (not in case '100*', but normally filter expression can be complicated and painful to parse). Perhaps with ASSERTERROR you can intercept the error and correct user input without the need of analysing filter syntax..

Just a guess - I haven't tried yet.

Slawek

freddy.dk

I Guess your problem will be, that if the statement after ASSERTERROR doesn't fail, then ASSERTERROR fails.
I would claim that the value of the function is limited to test.

Slawek_Guzek

Hmm,

How about :

PROCEDURE CheckFilter(UserFilterText) 
  SETFILTER(someintegerfield, UserFilterText);
  ERROR('Filter OK');
END;

somewhere else in the code:

ASSERTERROR CheckFilter(UserFilterText) ;
IF GETLASTERRORTEXT <> 'Filter OK' THEN BEGIN
  handleBadFilterStringHere
END;

Will this work ? (I'm asking as I don't have NAV2009 SP1 installed yet)

ara3n

Yes, it looks like it will work. I just tried it in NAV 2009 Sp1

ASSERTERROR catches the error. :-k

freddy.dk

Good catch - I stand corrected #-o

Slawek_Guzek

Well then ASSERTERROR seems to be perfect solution to catch and handle OCX and automation object errors, which are normally a big pain in the a...

Also perhaps for silent ROLLBACK:

PROCEDUE Rollback()
ASSERTERROR ERROR('');
END:


Slawek

pdj

This is very good news – great work Slawek and Rashed! =D>
The old IF CODEUNIT.RUN structure had two often unwanted characteristics:
1) It didn’t allow any open (un-committed) transaction before the call.
2) It either did a COMMIT or a ROLLBACK after the codeunit was executed.
Does the ASSERTERROR have the same characteristics?

kine

Difference from Codeunit.RUN is, that if the command after ASSERTERROR doesn't fail, the ASSERTERROR will fail, it means that it is not there to prevent error, it is there to assume error and if the error is not there, it is error... :-)

More about using this function can be found on the MSDN or on my blog... ;-)

Belias

Slawek Guzek wrote:

Well then ASSERTERROR seems to be perfect solution to catch and handle OCX and automation object errors, which are normally a big pain in the a...

Also perhaps for silent ROLLBACK:

PROCEDUE Rollback()
ASSERTERROR ERROR('');
END:


Slawek

I won't post topics before the weekend anymore, as i can't participate
Anyway, thanks for your valuable informations: i have a question about the quoted post:
what do you mean for silent rollback?Maybe that you can rollback the transaction until the asserterror error('') and then continue the rest of the process?

Slawek_Guzek

what do you mean for silent rollback?

A function which rollbacks your transactions but does not stop executing your C/AL code, so you can do something more in C/AL, instead of immediate returning control to the user.

Slawek

Slawek_Guzek

kine wrote:

it means that it is not there to prevent error, it is there to assume error ...

That's probably why Belias has asked about 'improper' use of ASSERTERROR

Belias

Slawek Guzek wrote:

what do you mean for silent rollback?

A function which rollbacks your transactions but does not stop executing your C/AL code, so you can do something more in C/AL, instead of immediate returning control to the user.

Slawek

THIS is cool...it can be useful, if it happens to be used by someone, let us know please. Thank you!
Thanks for the blog kine, I'll take a look at it ASAP
P.S.: you can find the link to the MSDN in the first post

Slawek_Guzek

I've finally installed NAV2009 on my PC and make a few tests of ASSERTERROR and potential 'improper' use..

Proposed Rollback() function works as expected, however it has side effects.

Test procedure looked like this:

MESSAGE('Before insert: %1', T97.COUNT);
T97.INIT;
T97."Table Name" := T97."Table Name"::"G/L Account";
T97.INSERT;
MESSAGE('After insert: %1', T97.COUNT);
Rollback();
MESSAGE('After Rollback: %1', T97.COUNT);

Rollback did rolled back change made to Table 97, but also suppressed all messages .

Slawek

kriki

[Topic moved from 'NAV 2009' forum to 'NAV Tips & Tricks' forum]

Miklos_Hollender

OK I think what's going on here is basically Microsoft is trying to make a Unit Testing framework for NAV, something like NUnit in .NET. Unit Testing is a fashionable idea, not sure if really useful for customizations but I think for add-ons, for the mission-critical parts of big add-onds can be useful. This is what this is about, this is also what this is about: http://www.mibuso.com/dlinfo.asp?FileID=1154

You can read about the concept of Unit Testing here: http://en.wikipedia.org/wiki/Unit_testing

And you can see a quick NUnit example because most likely NAV's testing functions are evolving towards this direction http://en.wikipedia.org/wiki/NUnit#Example

Belias

there's a (still) undocumented (and not very well designed :whistle: ) example about this, from microsoft:
http://www.mibuso.com/forum/viewtopic.php?f=7&t=38494

pdj

It is (almost) always great with new functionality in NAV, but I don't think this level of unit test is what the channel needs. I would rather have better ability to automate user-interactions. I would really like a tool where I could record a series of clicks and input-values, and then a way to compare selected results with the expected results.
This provided kind of unit testing is close to useless in the NAV projects I have been involved in. We have tried several visual test tools, but due to the non-standard control handling in NAV we have ended up using people. We have 8-12 testers sitting 3-4 days every half a year to go through our test scripts before we release a major version.
If we could automate this with a proper test tool, we would run it each night, and could quickly find when a change had some unforseen consequenses in other parts of the solution.

But since the ASSERTERROR can't be used for test scripts (imo) it's great it can be used for something else 8)

kine

You need to take the tool as tool for testing basic functions, not "whole processes". You need to create tests for each function you create, than you can test the solution. You cannot test in a way, that one test function will test if whole posting process is OK. (problem is, that the posting is one big function and creating test which will test this function is too complicated).

pdj

kine wrote:

You need to take the tool as tool for testing basic functions, not "whole processes".

Yes, I expect it works as your blog and MS describes it. But that just show me that I can't use it.

kine wrote:

... and creating test which will test this function is too complicated).

Yes, it might be too complicated to be used, but I am more afraid that the tests will be useless. If I (god forbid it) was told to make test-code for each of my functions, I could do it. But it wouldn't say anything about wheter or not the solution works as expected. We would just end up with twice as much code in our test-codeunits as the codeunits we wish to test. It wouldn't make any sense.

Miklos_Hollender

PDJ,

actually I think automated GUI testing is kind of possible with the RTC - I'm thinking along the lines of somehow catching communication between the client and the service layer. If that's somehow caught and logged, then expose pages as web services and just write a program that reads the log and generates a C# program calling those web services. The hard question is how to catch the communication. Is it encoded?

pdj

I expect the GUI of the RTC can be scripted like allmost all other standard Windows application. You don't need to use any of the tricks you suggest. The problem with the classic C/Side client is, that is was originally made before Microsoft had windows classes for Windows 95, so Navision Software had to make their own.
None of the solutions I'm working with are converted to the RTC. Our customers are more focused on our added functionality and the overall productivty of their users, than upgrading just because MS has released a new GUI. (I know I'm oversimplifying, but I hope you know what I mean 8))

Miklos_Hollender

The problem is that in 2010 you can only get an add-on certified if it's fully working on RTC. At least that's the rumour I have heard, I can't verify this rumour, perhaps you might want try to find out if it's true, you are physically much closer to Vedbaek than I am

Belias

Miklos Hollender wrote:

The problem is that in 2010 you can only get an add-on certified if it's fully working on RTC. At least that's the rumour I have heard, I can't verify this rumour, perhaps you might want try to find out if it's true, you are physically much closer to Vedbaek than I am

Fully working does not mean without bugs