-
-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make error handling more compatible to VO #111
Comments
Hi Wolfgang, That was not forgotten, it's just one of the things that will have to wait for probably 2.1 or 2.2, same with being able to pass arguments by reference to untyped methods, debugging improvements, further VS integration improvements etc. Just not possible to do all we wanted for 2.0, but obviously development does not stop there. If something like you propose will be implemented (after making enough investigation to make sure it is a viable solution), it will be implemented most probably optionally only, with a compiler option. But still, I suspect it will not help much, because IMO the biggest difference between VO and .Net is that VO provides error handling even without BEGIN SEQUENCE blocks at all, allowing you to continue execution after the error has happened, from the next line! End even if you have SEQUENCE blocks like this: BEGIN SEQUENCE CallSomeCodeThatCAusesAnException() // rest of the code RECOVER END SEQUENCE then if an exception happens inside the call, then program control is not automatically moved to the RECOVER section, but the user (or the programmer) still has the option to keep executing the "rest of the code" section, or even the code inside the function that caused the exception and has no error handling itself at all. This is indeed a powerful feature of VO, but unfortunately there's nothing in .Net that could be used to emulate this. Unless maybe if the compiler automatically (optionally again) inserted a TRY block for EVERY single line of code, implementing this kind of error handling. Of course this would lead to HUGE exes/dlls, but maybe this is not a very big problem. Probably it would also hurt performance a lot, but then again maybe it will not be too much...it's something to experiment with. |
In the next build the default error handler (set with SetErrorBlock()) will point to an internal error handler DefError() inside XSharp.RT that takes case of sharing violation errors like the VO error handler (so DbUseArea() will return FALSE) and it will display a MessageBox with similar options as the VO error handler. This error handler will also (wen the SetErrorLog() is set to TRUE) create a VOERROR.LOG like VO does. Of course you can customize this:
|
See #916 for a proposed solution |
… SEQUENCE .. END support. This support requires 2 runtime functions that can be overridden in user code. Examples of these functions can be found in test R824.
Closing this ticket. #916 contains the real work |
https://www.xsharp.info/forum/public-chit-chat/1372-error-handling-in-x-vs-vo :
in my VO code I'm using begin/end sequence very often to control where an error is occurring, and to inhibit that the program crashes because of a foreseable error.
The globally set errorblock helps a lot to keep my code small. In X# there is no global error handler available
The real problem is that in VO you can set your own errorblock, and it is called every time an error is occurring.
In .NET this is not the case - you have to catch the errors by yourself in the catch block.
Therefore my suggestion was to replace the VO begin/end sequence by something like this (pseudo-code):
try
...code...
catch oEx as Exception
ExecuteErrorBlock( oEx )
...code...
end try
or even a sequence without recover block with the same construct.
Wolfgang
The text was updated successfully, but these errors were encountered: