runtime error source location decoration

[Dan Kortschak]

Hi,

I'm trying to debug a reasonably complex expression that is failing
with a no such overload error. Unfortunately I'm unable to construct a
reproducer locally to be able to figure out exactly where in the
expression this is happening. Is there some way to ask the interpreter
to decorate errors with a code location?

thanks
Dan

[Dan Kortschak]

On Tue, 2023-11-07 at 19:55 +0000, 'Dan Kortschak' via CEL Go

It looks like part of the machinery for this is available in v0.18.2
with the addition of the celast.AST.NativeRep method. With this it
looks like we can now ast.NativeRep().SourceInfo().GetStartLocation(id)
to be able to get the position of the issue. However, by the time we
are back in Go, we don't have the node ID. This *could* be stashed in
types.Err by the runtime, with a method on types.Err to retrieve it.
This could either be done automagically by the runtime without user
intervention by decorating with the node ID, which is known at this
point AFAICS, if a returned val is an Err.

Dan

[Tristan Swadell]

Hi Dan,

The program plan steps do contain the expression id; however, these id are not added to the error value when errors are surfaced. It should be possible to do this, but I haven't had the time.

-Tristan

--
You received this message because you are subscribed to the Google Groups "CEL Go Discussion Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cel-go-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cel-go-discuss/910fea6078bd989b083ea411f3d60a493afa695f.camel%40kortschak.io.

[Dan Kortschak]

On Tue, 2023-11-21 at 10:58 -0800, 'Tristan Swadell' via CEL Go

Discussion Forum wrote:
> The program plan steps do contain the expression id; however, these
> id are not added to the error value when errors are surfaced. It
> should be possible to do this, but I haven't had the time.

Thanks, Tristan.

Depending on time availability this is something I could take on. I
expect that this would add some API surface, but I can put something
initial together to see if it would fit with your plans.

Dan

[Tristan Swadell]

My guess is that the planner could probably attach an id to an Error value, but that's as far as I've thought.

-Tristan

--
You received this message because you are subscribed to the Google Groups "CEL Go Discussion Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cel-go-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cel-go-discuss/555231941bc800f3e7e22cb41b16bcdffc39f3f3.camel%40kortschak.io.

[Dan Kortschak]

On Tue, 2023-11-21 at 11:32 -0800, 'Tristan Swadell' via CEL Go

Discussion Forum wrote:
> My guess is that the planner could probably attach an id to an Error
> value, but that's as far as I've thought.

Yeah, that was my intention. This requires some additional API on
types.Error.

Dan