Control flow with exceptions

[ncannasse]

It is a often used principle in FP to use exceptions for control flow.
These exceptions can hold complex values that should not be stringified (they might have recursive values loops)

Or I noticed that's exactly what js.HaxeError does.... it Std.string the exception value when the exception is created...

Could this be avoided ?

I had to change hscript implementation that was throwing exception in the form or throw SReturn(value) because of the bugs it produces.

Maybe the recent PR #6713 also causes some regression here, by using Std.string instead of String(value) ping @nadako

[nadako]

Hmm, it shouldn't use Std.string, and I believe most JS engines have protection against recursion loops when stringifying values. Also I think even Std.string have protection against too many levels of recursion, no?

What exactly is the issue there?

[ncannasse]

I had a stack overflow error when returning a complex expression in hscript. I fixed it with HaxeFoundation/hscript@8c04831
It involved a StringMap.toString() which itself was calling Std.string

[ncannasse]

Try running the following on Node:

class Main  {

	static function main() {
		try {
			var m = new Map<String,Dynamic>();
			m.set("recurse",m);
			throw m;
		} catch( e : String ) {
			trace("CAUGHT string ?");
		}
	}

}

it seems String(m) triggers m.toString()

[nadako]

Right, custom toString... The problem here is that we want to fill some message for thrown errors or they'll be incomprehensible and doing String(val) sounds like the best thing we can do. Gotta think about it, but right now I'm thinking that maybe it's more of a Map issue.

[ncannasse]

triggering toString when throwing is bad for performance anyway. Can't we add it in Error.toString() so it's only triggered if we print the exception itself ?

…

On Sat, Nov 25, 2017 at 12:43 PM, Dan Korostelev ***@***.***> wrote: Right, custom toString... The problem here is that we want to fill some message for thrown errors or they'll be incomprehensible and doing String(val) sounds like the best thing we can do. Gotta think about it, but right now I'm thinking that maybe it's more of a Map issue. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6754 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-bwCTEJWyi9UvCpJPArUSyOEFJAdwGks5s5_1_gaJpZM4QpuKH> .

[nadako]

There should be some way, toString or maybe a js getter for the message property, gotta look into it...

[ncannasse]

Yes, that would work too and be more backward compatible

…

On Sat, Nov 25, 2017 at 9:19 PM, Dan Korostelev ***@***.***> wrote: There should be *some* way, toString or maybe a js getter for the message property, gotta look into it... — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6754 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-bwIBF94NPjcFAlh35Gj9rI7qcx9LVks5s6HZVgaJpZM4QpuKH> .