Improve debug stack trace for custom error types

[joshgoebel]

I see:

// TODO: Print something a little useful here. Maybe the name of the error's
// class?

So what about:

ObjClass* klass = wrenGetClass(vm, fiber->error);
vm->config.errorFn(vm, WREN_ERROR_RUNTIME,
                       NULL, -1, 
                       AS_CSTRING(wrenStringFormat(vm, "[error object: @]", klass->name))
                       );

Are there other cases we need to worry about?

[mhermier]

While I agree it would solve the comment, I'm not sure it is the best way to solve the issue. The fact that stack printing is written in C is of a great convenience, but has a huge drawback of being limited at printing native types only.

[joshgoebel]

but has a huge drawback of being limited at printing native types only.

No, this code works with user defined classes also. (I tested it with one)

We can also leave the TODO in place (further improvements welcome)... but it felt like this would be a step forward, no? My Wren in Wren rewrite of the CLI processes stack traces on the Wren side, so we have a lot more flexibility but that currently isn't possible (desirable?) with the CLI.

It's possible we may need to consider other native types than strings and classes here, that's why I was asking for feedback.

[mhermier]

but has a huge drawback of being limited at printing native types only.

No, this code works with user defined classes also. (I tested it with one)

I didn't said that it was not working correctly, but that representation of non native types was limited.

Eg I have a Char class, it would be more interesting to have the character printed than "instance of class Char" or alike.

We can also leave the TODO in place (further improvements welcome)... but it felt like this would be a step forward, no? My Wren in Wren rewrite of the CLI https://github.com/joshgoebel/wren-console/ processes stack traces on the Wren side, so we have a lot more flexibility but that currently isn't possible (desirable?) with the CLI.

It can be done. This is definitively a pro to allow access the stack of fibers.