blokyk
f91bdc9367
frames manually added with `addErrorContext` are generally a lot more useful/informative to the average user than other frames, esp. in the module system, which can create much better error messages than we can. however, before this change, frames from addErrorContext were truncated by default if they weren't in the first 3 frames, so they were basically useless (with `--show-trace`, you're dredging through 250 frames of module shenanigans just to spot one singular line). this change also removes the frames for _the call to_ `addErrorContext`, which is just pure noise. the way this change is done hopefully leaves a bit of space for future similar changes to error printing, by introducing a new `TraceKind` enum that can be used to categorize traces (i haven't done that in this CL because that would be a pretty herculean task, given all the calls to `BaseError::addTrace` in the codebase, and we probably want to be careful about what categories we choose). the actual printing code could definitely be improved tho... (e.g. by iterating twice through the trace stack instead to first pick out the most important traces and _then_ printing less "important" traces if there's space left) Change-Id: I52acc52f231991a9f2309d9cecae362397c6888c
1.0 KiB
synopsis, cls, category, credits, issues
| synopsis | cls | category | credits | issues | ||
|---|---|---|---|---|---|---|
| Always print frames from `addErrorContext` in error traces |
|
Improvements |
|
The builtins.addErrorContext
function allows an author to add artificial stack frames with custom messages to
help end-users understand the context of an error and the path the code took to
get there, without having to read and understand the original source code. A
particularly notable user of this is the Nixpkgs module system, which adds
custom frames detailing what option it's evaluating or which definition it's
looking at.
However, previously, these frames would end up treated just as any other,
meaning they would most often not be visible without --show-trace; yet, using
--show-trace, they would be drowned out in the noise of the hundreds of other
frames, rendering them just as unusable.
With this change, these frames are now unconditionally shown, even without
--show-trace, which makes basic error traces much more informative.