xsharp.eu

Hi Chris,

one thing is to make the SDK code better - and this can be done once for us all. But there are tons of user written code, milions of lines of code, that need to be run with the X# runtime, and that cannot be rewritten or revisited in detail. This code will contain errors, either never discovered, or without effect when run in with the VO runtime, and the X# runtime must help to find and fix these.
This is really a big job!

Wolfgang

Hi Wolfgant,

wriedmann wrote: a functionality to get errors out of "begin-end sequence" constructs is absolutely needed.

Although I understand what you say, to recover from an error in a Construct as "complex" as in the Dbf classes as Chris stated was complex, although yes a "global" error trap might do the trick, think it will still be quite a challenge to implement.

Just my 2c.

Regards,

Hi Johan,

I agree that it will be a challenge, but it was also a challenge to build a product like X#. So I'm pretty sure the development team will come up with a solution.
It is very important that they understand the problem, so it is possible to search for a solution.

Wolfgang

Guys,

Our xporter already insets a TRY .. CATCH .. FINALLY in the code of the start method.

Franks example does not have that, which causes his program to "silently crash".

The simplest solution that I can think of would always add a try .. catch to the start function (except for the Core dialect) to make sure that exceptions would be catched. Of course when such a TRY .. CATCH already exists then the compiler would do nothing.

What do you think of that ?

Robert


PS: the code with the AAdd() produces a XS0165 warning about an uninitialized local "aD" on my machine, so the compiler does warn you that there is a potential problem.
I know that many people disable this warning, but as you can see in this example, that is always a good idea.

Hi Robert,

the main problem is not the Start() method. The main problem are the myriads of "begin - end sequence" constructs missing a "recover" part not only in the GUI classes, but in user code.
In VO code, when an error is occurring there, the standard errorblock kicks in and shows the error. The "begin - end sequence" is there only to not make crash the program.
In migrated code the code fails silently and neither the user nor the programmer knows where any why.

Therefore X# should add a "catch" block to these sequences, calling a globaliy set error handler.

Wolfgang

Hi Robert,

Our xporter already insets a TRY .. CATCH .. FINALLY in the code of the start method.

yes this is right, and my sample for Chris is a exported Sample

Franks example does not have that, which causes his program to "silently crash".

that is not correct, the main code and the Sample for Chris have this code and "Crash Silent"


Frank

Wolfgang,
In the GUI Classes there are only 2 BEGIN SEQUENCE .. END SEQUENCE CONSTRUCTS. These are in DataWindow:FieldPut() and DataWindow:FieldGet(). They both have a recover using that looks like:
RDD Classes contains a lot of BEGIN SEQUENCE.. END SEQUENCE constructs but these all have a RECOVER USING that saves the error in an ivar of the server and then call the Error() method on the server class.
SQL Classes contains one (1) BEGIN SEQUENCE. This also has a recover but that is empty.

So what exactly is the problem ?

Robert

Hi Robert,

the main problem is user code.

I have done a search in one of my largest projects, and there are 692 occurences of "begin sequence", and most of them don't have any "recover" statement there.

In VO this is no problem at all, because the errorblock catchs in, and does all the error handling.

When these sequences are translated to "try - end try" blocks in X#, the code will fail silently without any notification of the user.

Wolfgang

Wolfgang,

Would it be enough if we call the global error handler that is registered with ErrorBlock() from a compiler generated RECOVER statement ?

Robert

Hi Robert,

that would be the best solution.

Wolfgang