Ability to programmatically control dataflow error traces

[radeusgd]

Currently, after #8608 full dataflow error stack traces are controlled by the JVM assertions -ea setting.

This makes the setting meaning a bit too overloaded, and while it is a good temporary solution, we probably need some more fine grained control.

Ideally, we should make it possible to enable full stack traces only for a piece of code that is being debugged, not necessarily the whole program.

As suggested in the discussion, it seems that the best idea is to implement an additional special-use context Context.Tracing (or perhaps Context.Dataflow_Error_Stack_Traces if we want a more 'precise' name 🙂) that will allow to enable the opt-in full stack traces in dataflow errors.

Example:

foo =
    x = Error.throw 42 # only simplified 1 frame stack trace
    Context.Tracing.with_enabled <|
        y = Error.throw 23 # full stack trace

Once that feature is implemented, we can probably get rid of the -ea controlling the tracing, as Context.Tracing would allow for the more fine-grained control.

Alternatively, I think it may still be useful to globally override the tracing settings by a CLI parameter (i.e. while Context.Tracing is disabled by default, we could have a CLI parameter that makes it enabled by default). This way, we could run a test suite with full tracing in a much easier way. But to avoid overloading the meaning of -ea, I suggest to add a flag to the engine runner like --enable-full-stack-traces-by-default.

[GregoryTravis]

After reading the previous issues and PRs, here is my understanding. I will:

• Add Dataflow_Stack_Trace constructor to Runtime.Context
• Add a State parameter to DataflowError.withoutTrace()
• Pass State from every node calling withoutTrace(), including especially ThrowErrorNode
• In DataflowError.withoutTrace(), check the Dataflow_Stack_Trace context setting to decide about including the full stack trace (instead of assertsOn)
• Add a --enable-full-stack-traces-by-default, which sets Dataflow_Stack_Trace by default

Does this sound right, @JaroslavTulach and @radeusgd?

[JaroslavTulach]

Add a --enable-full-stack-traces-by-default, which sets Dataflow_Stack_Trace by default

The proliferation of various specialized options shall stop one day! bin/enso --help is too long already. Isn't the initial value of Runtime.Context already influenced by --execution-environment option?

Context.Tracing.with_enabled <|
        y = Error.throw 23 # full stack trace

Context.Tracing.with_enabled is useful of its own. Let's start with it and let's leave new CLI options for later.

[GregoryTravis]

Add a --enable-full-stack-traces-by-default, which sets Dataflow_Stack_Trace by default

The proliferation of various specialized options shall stop one day! bin/enso --help is too long already. Isn't the initial value of Runtime.Context already influenced by --execution-environment option?

Context.Tracing.with_enabled <|
        y = Error.throw 23 # full stack trace

Context.Tracing.with_enabled is useful of its own. Let's start with it and let's leave new CLI options for later.

Ok, I'll leave out the CLI argument for now. But what are the allowable values for --execution-environment? It looks like it can be live or design.