Summary
Lua.RuntimeException exposes a structured to_map/2 for programmatic
consumers, but only when you hold the exception struct. In several paths a
host only has the rendered error string, and the only way to recover fields
like source / line / message from it is to scrape the human-facing
rendering apart with a regex. That rendering is an internal presentation detail
— it has changed shape between releases — so any consumer that parses it is
coupled to a format that isn't a documented contract.
This is the runtime-error analog of #361, which exposed structured parse
errors for the same reason.
Current state
Lua.RuntimeException.to_map/2 returns the structured map (message,
source, line, call_stack, source_context, suggestion,
error_kind) — but it takes the struct.Exception.message/1 renders a plain, single-line string of the form
"<prefix><body> (at <source>:<line>)" (via message/1 + the private
location_suffix/1), with the variants " (at <source>)" and
" (at line <N>)" when only one of source/line is known.- There is no public function for the reverse direction — string →
structured map. A consumer that only has the rendered string must
reconstruct source / line by matching the (at source:line) suffix with
a regex.
- That suffix format is not documented as a stable contract and has changed
between releases (an earlier version rendered a leading source:line:
prefix; the current one uses the trailing (at source:line) form). A
downstream parser coupled to it breaks silently across such a change.
Why a host ends up with only the string
Whenever an error is surfaced as a value rather than as the struct — e.g. the
reason captured from a protected call, an error propagated out through Lua
code, or a message read back from a structured log — the structured fields have
already been flattened into the rendered string. Recovering them means
re-parsing the presentation layer.
Proposal
Expose a public parser that maps a rendered runtime-error string back to the
same map shape to_map/2 produces — e.g. Lua.RuntimeException.from_message/1
(or a string-accepting clause of to_map). Since the library owns the forward
rendering (message/1 / location_suffix/1), it is the natural owner of the
inverse, and consumers stop depending on an undocumented format:
Lua.RuntimeException.from_message("Lua runtime error: boom (at <eval>:4)")
#=> %{message: "boom", source: "<eval>", line: 4, call_stack: [], ...}Alternatively (or in addition), document the message/1 location-suffix format
as a stable, supported contract so external parsers can rely on it.
Related
Summary
Lua.RuntimeExceptionexposes a structuredto_map/2for programmaticconsumers, but only when you hold the exception struct. In several paths a
host only has the rendered error string, and the only way to recover fields
like
source/line/messagefrom it is to scrape the human-facingrendering apart with a regex. That rendering is an internal presentation detail
— it has changed shape between releases — so any consumer that parses it is
coupled to a format that isn't a documented contract.
This is the runtime-error analog of #361, which exposed structured parse
errors for the same reason.
Current state
Lua.RuntimeException.to_map/2returns the structured map (message,source,line,call_stack,source_context,suggestion,error_kind) — but it takes the struct.Exception.message/1renders a plain, single-line string of the form"<prefix><body> (at <source>:<line>)"(viamessage/1+ the privatelocation_suffix/1), with the variants" (at <source>)"and" (at line <N>)"when only one of source/line is known.structured map. A consumer that only has the rendered string must
reconstruct
source/lineby matching the(at source:line)suffix witha regex.
between releases (an earlier version rendered a leading
source:line:prefix; the current one uses the trailing
(at source:line)form). Adownstream parser coupled to it breaks silently across such a change.
Why a host ends up with only the string
Whenever an error is surfaced as a value rather than as the struct — e.g. the
reasoncaptured from a protected call, an error propagated out through Luacode, or a message read back from a structured log — the structured fields have
already been flattened into the rendered string. Recovering them means
re-parsing the presentation layer.
Proposal
Expose a public parser that maps a rendered runtime-error string back to the
same map shape
to_map/2produces — e.g.Lua.RuntimeException.from_message/1(or a string-accepting clause of
to_map). Since the library owns the forwardrendering (
message/1/location_suffix/1), it is the natural owner of theinverse, and consumers stop depending on an undocumented format:
Alternatively (or in addition), document the
message/1location-suffix formatas a stable, supported contract so external parsers can rely on it.
Related
call_functionreturning terminal-formatted string as:errorreasonpcallreturning stringified error objects