Allow user to turn off injectStacktrace

[Graveflo]

adds asyncTracebacks compile flag to stop asyncfutures module from overwriting user specified error messages

[Graveflo]

as a side note: it seems like the only utility in these "async tracebacks" is to condense the stack trace removing commonality from "reraised from" traces. It's not a bad idea to do that in general to make them easier to read, so maybe that is a better solution to injectStacktrace. There would probably need to be some kind of marker to signify that the stack trace includes part of the previous trace. like:

a/b.nim(47)
a/c.nim(30) <-- some marker here
a/d.nim(30)
[[reraised from:
...
a/e.nim(30)
]]

[arnetheduck]

I think the fundamental design flaw here is that text-based stack traces are generated at all at the raise site - ie the natural thing to do here would have been to keep a chain of nested Exception instances, each of which contains a list of instruction pointers that can be translated to text on demand should they be asked for, formatting them at the point where they are consumed (ie printed to screen, string or log) instead of doing so up-front and clobbering the msg field.

This approach would also allow deduplicating them more productively, ie by filtering out any "common base" pointers.

[Graveflo]

For these async trackbacks specifically, something like that was the first thing that I tried to do. I didn't want to add anything to FutureBase or recolor the final exception, and in the end it seemed impractical to re-use the current data structures for this. Maybe that is why it was done this way to begin with as a lazy hack. I didn't try too hard though because it's hard to justify the time investment when the end result is just slight convenience. So agreed. Either way, given the current behavior, I do wish to turn this off when needed.

[nitely]

@Graveflo I think this injecting the stack trace into the msg is from before "reraised from" existed and it should be removed. Unless there is something I'm missing there is no point to it. A func to get the nicer stack trace (ie getAsyncStackTrace*(err: ref Exception): string {.raises: [].}) should be added instead.

[Graveflo]

@Graveflo I think this injecting the stack trace into the msg is from before "reraised from" existed and it should be removed. Unless there is something I'm missing there is no point to it. A func to get the nicer stack trace (ie getAsyncStackTrace*(err: ref Exception): string {.raises: [].}) should be added instead.

I'm fine with it being removed. In my experience the feature does something to the effect of factoring the stacks of "reraised from" at the expense of tampering with the exception message re-purposing it as a buffer. I do find it easier to look at that message then scrolling through the reraised call stacks when debugging. I don't think anyone really needs it, and it is dirty so removing it makes sense. Surely a better solution can be made.

[nitely]

@Graveflo Before I added that filtering here it used to just contain the top traceback. There was no point to it afaik. I guess it's nice that it shows the smaller traceback on an unhandled exception now, but it being part of the msg it's sometimes confusing too.

I do find it easier to look at that message then scrolling through the reraised call stacks when debugging.

Yes, it's hard to parse very long stack traces, and that's why I added it. But as I said earlier a getAsyncStackTrace would serve the same purpose. I tried doing this for chronos here.