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

[cs] broken exception handling when using callback #8519

Closed
AlexHaxe opened this issue Jul 6, 2019 · 4 comments · Fixed by #11551
Closed

[cs] broken exception handling when using callback #8519

AlexHaxe opened this issue Jul 6, 2019 · 4 comments · Fixed by #11551
Labels
bug platform-cs Everything related to c#
Milestone

Comments

@AlexHaxe
Copy link
Contributor

AlexHaxe commented Jul 6, 2019

During benchmark testing with formatter I found out that C# has an issue with catching exceptions thrown by a callback. I reduced my code down to a basic example:

class Main {
	static function main() {
		run(throwsException);
	}

	public static function run(cb:Void->Void) {
		try {
			cb();
		} catch (e:String) {
			trace("caught " + e);
		}
	}

	public static function throwsException() {
		throw "my exception";
	}
}

expected output: "my exception caught"
C# output: "unhandled exception" + stacktrace

broken for both Haxe 3 and 4

@nadako
Copy link
Member

nadako commented Jul 6, 2019

Not a generator issue for once, but something in the Runtime.callMethod implementation.

@nadako nadako added bug platform-cs Everything related to c# labels Jul 6, 2019
@nadako
Copy link
Member

nadako commented Jul 6, 2019

So, MethodBase.Invoke wraps thrown exception in a TargetInvokationException, so we should do try method.Invoke(...) catch (e:TargetInvokationException) throw e.InnerException.

The problem is how to preserve stack trace without horrible hacks. With .NET 4.5 we can do ExceptionDispatchInfo.Capture(ex.InnerException).Throw(), but before that....

@nadako
Copy link
Member

nadako commented Jul 6, 2019

In general we should rework how method closures are created in C#, these should not go through reflection. I had a branch with the rework a couple years ago but never got it to work 100% due to some problems with access control.

@nadako
Copy link
Member

nadako commented Jul 6, 2019

branch with the rework

I think that was it https://github.com/nadako/haxe/tree/gencommon_faster_method_closures

@RealyUniqueName RealyUniqueName added this to the Bugs milestone Jul 10, 2019
@Simn Simn modified the milestones: Bugs, Later Mar 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug platform-cs Everything related to c#
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants