Not sure if X# takes better care of this, but our main programs are in VO. Sometimes the program crashes without any message; the program just quits, not even making an entry in the Windows application log. Hence it is very difficult to find the cause, especially when it happens in a program where the same code seems to run all the time but nevertheless the crash could happen suddenly.
Now I had such a situation which I could reproduce and pinpoint to a line of code: from
My question is: why does the program quit? I would expect a runtime error, something like Invalid type as the unintentionally changed code should yield a logic value.
I am not sure what compiler options could/would/might cause any such an issue because there are several, such as: Type Inference, Overflow checking, etc.
It is best to create a small test app and see if you can reproduce the issue with different compiler options.
Hi Dick,
I have seen similar things in VO, but always when there is some begin/end sequence construct in game.
VO applications generally are rock solid, but sometimes things like this are occurring.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
I remember also these bad errors in VO with the program quitting without a message.
We could avoid this in most cases if the program part had a separate Exceptionhandler with the begin sequence... pattern.
I think that handling exceptions as early as possible is generally important, also in X#. This allows some programming errors with clear error messages and leaves the program stable. The standard error handler should only be called for unhandled exceptions.
Thank you for all your comments. For a moment I thought I had it solved, meaning that Jamal's first suggestion, the compiler options, were the cause.
I implemented the code, opening the same dbserver the same way as in the program that crashed, in a simple VO test program, and I got the run time error as expected with the faulty line missing '==0'. Then I noted the original calling program did have the whole left corner of objection unchecked, contrary to the test program.
But unfortunately, checking the options in the program did not give the error and...unchecking all these options did not cause the test program to crash without an error.
So yes, it must be something in program but I don't know what else it could be. And to answer Jamal's question: I use 2.8 SP4 (2838) - I think everyone does except some hobby users or users with a very old project maintained last long ago.
The main reason it would still be interesting to find the cause is that it could probably prevent some more of these crashes. As Wolfgang says, VO programs are rock solid but there are always some unexplainable crashes and I feel I could be close to preventing some of them. I also have an extensive error handling system in place but also that did not prevent the program from quitting. After all, even without the error handler, the default error handler should have kicked in, as it did in the test program.
That's weird! May be Robert (Mr. Compiler) can jump it and shed some light.
My suggestions for now:
1. Search your program and libraries for ALTD() and either remove or comment out to prevent any side effects.
2. Reindex the VO repository, touch all library dependencies and your program.
3. Set the compiler options as shown image below.
The compiler settings were exactly as in your screenprint (later I checked all 4 in the lower left box without result). I know that Altd() could influence the runtime exe too, and indeed there were a few ones left which I removed, but most conditional and none in this part of the program. And I reindexed and the program still quits (without the currently added error handler in this specific method).
But as I can not reproduce the issue in a test program, something in this program is likely to interfere. I don't know what. There are no other error handlers and it's just a simple DataDialog from which the (offending when ==0 is left out) method is called.
So I know why & where it did quit, solved that, can catch an error now with re\\success. But it still leaves me puzzled why it did not give me a proper run time error and knowing that would help in other -exceptional but happening- situations where this no-error-quitting occurs as well. So if Robert has an idea it is indeed welcome.