Skip to content
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

Closed
cpyrgas opened this issue Jul 27, 2019 · 5 comments
Closed

Make error handling more compatible to VO #111

cpyrgas opened this issue Jul 27, 2019 · 5 comments

Comments

@cpyrgas
Copy link

cpyrgas commented Jul 27, 2019

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

@cpyrgas cpyrgas added this to To do in Runtime via automation Jul 27, 2019
@cpyrgas cpyrgas added this to To do in Compiler via automation Jul 27, 2019
@cpyrgas
Copy link
Author

cpyrgas commented Jul 27, 2019

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.

@RobertvanderHulst RobertvanderHulst added this to the 2.2 and Later milestone Aug 3, 2019
@RobertvanderHulst RobertvanderHulst added the VO VO Dialect label Sep 20, 2019
@RobertvanderHulst RobertvanderHulst modified the milestones: 2.2 , November 2019, January 2020 Nov 18, 2019
@RobertvanderHulst RobertvanderHulst modified the milestones: April 2020, May 2020 May 2, 2020
@RobertvanderHulst RobertvanderHulst modified the milestones: May 2020, June 2020 Jun 5, 2020
@RobertvanderHulst RobertvanderHulst added this to To do in Later Apr 8, 2021
@RobertvanderHulst
Copy link
Member

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:

  • set your own errorblock
  • set the name of the error log file (with the new function SetErrorLogFile())

@RobertvanderHulst RobertvanderHulst removed this from the August 2020 milestone Apr 8, 2021
@RobertvanderHulst RobertvanderHulst added this to To do in June 2021 May 28, 2021
@RobertvanderHulst RobertvanderHulst removed this from To do in June 2021 Jun 22, 2021
@RobertvanderHulst RobertvanderHulst removed this from To do in Later Dec 6, 2021
@RobertvanderHulst RobertvanderHulst removed this from To do in Runtime Jan 12, 2022
@RobertvanderHulst RobertvanderHulst removed this from To do in Compiler Jan 12, 2022
@RobertvanderHulst
Copy link
Member

See #916 for a proposed solution

RobertvanderHulst referenced this issue in X-Sharp/XSharpDev Jan 26, 2022
… 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.
@RobertvanderHulst RobertvanderHulst added this to To do in January 2022 via automation Jan 26, 2022
@RobertvanderHulst RobertvanderHulst self-assigned this Jan 26, 2022
@RobertvanderHulst RobertvanderHulst moved this from To do to Needs Testing in January 2022 Jan 26, 2022
@RobertvanderHulst RobertvanderHulst added this to To do in February 2022 via automation Feb 2, 2022
@RobertvanderHulst RobertvanderHulst moved this from To do to Needs Testing in February 2022 Feb 2, 2022
@RobertvanderHulst RobertvanderHulst added this to the X# 2.11 milestone Feb 10, 2022
@RobertvanderHulst RobertvanderHulst removed this from Needs Testing in February 2022 Feb 24, 2022
@RobertvanderHulst RobertvanderHulst added this to To do in March -April 2022 via automation Feb 24, 2022
@RobertvanderHulst RobertvanderHulst modified the milestones: X# 2.11, X# 2.12 Feb 24, 2022
@RobertvanderHulst RobertvanderHulst moved this from To do to In progress in March -April 2022 Feb 24, 2022
@RobertvanderHulst
Copy link
Member

Closing this ticket. #916 contains the real work

March -April 2022 automation moved this from In progress to Needs Testing May 9, 2022
@RobertvanderHulst RobertvanderHulst moved this from Needs Testing to Done in March -April 2022 May 9, 2022
@cpyrgas
Copy link
Author

cpyrgas commented May 12, 2022

Follow up in #881 and #916

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Development

No branches or pull requests

2 participants