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
Break only when Debugging
Break only when Debugging
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
- lumberjack
- Posts: 727
- Joined: Fri Sep 25, 2015 3:11 pm
- Location: South Africa
Break only when Debugging
Hi Wolfgant,
Just my 2c.
Regards,
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.wriedmann wrote: a functionality to get errors out of "begin-end sequence" constructs is absolutely needed.
Just my 2c.
Regards,
______________________
Johan Nel
Boshof, South Africa
Johan Nel
Boshof, South Africa
Break only when Debugging
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
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
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Break only when Debugging
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.
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.
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
Break only when Debugging
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
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
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
-
- Posts: 280
- Joined: Sat Dec 12, 2015 2:22 pm
- Location: Germany
Break only when Debugging
Hi Robert,
Frank
yes this is right, and my sample for Chris is a exported SampleOur xporter already insets a TRY .. CATCH .. FINALLY in the code of the start method.
that is not correct, the main code and the Sample for Chris have this code and "Crash Silent"Franks example does not have that, which causes his program to "silently crash".
Frank
Break only when Debugging
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
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:
Code: Select all
RECOVER USING oError
BREAK oError
END SEQUENCE
SQL Classes contains one (1) BEGIN SEQUENCE. This also has a recover but that is empty.
So what exactly is the problem ?
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
Break only when Debugging
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
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 Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Break only when Debugging
Wolfgang,
Would it be enough if we call the global error handler that is registered with ErrorBlock() from a compiler generated RECOVER statement ?
Robert
Would it be enough if we call the global error handler that is registered with ErrorBlock() from a compiler generated RECOVER statement ?
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
Break only when Debugging
Hi Robert,
that would be the best solution.
Wolfgang
that would be the best solution.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it