Stack traces, human panic, and failure::Context are essentially runtime docs. They provide contextual information when something goes wrong. Output depends on what went wrong. Also you'll never want them ahead of time, but only when inspecting the program.
-
Show this thread
-
I guess the compiler error messages are quite similar. Super contextual, and completely dependent on the input state you gave it. Imagine if we could make a similar leap the compiler has for compilation errors, but for in-program runtime error reporting. We should experiment :D
1 reply 2 retweets 13 likesShow this thread -
(oh oh oh, just like, imagine if debug Rust could point to the line in source that the program broke, and explain how it broke, and why. Would be so much better than staring at a 50 line stack trace)
3 replies 0 retweets 9 likesShow this thread -
Replying to @yoshuawuyts
The problem is code ownership and responsibilities, what invariant went wrong is not something the compiler can figure out because it's a higher level concept not encoded in the type system. (If it could be, it wouldn't be a panic)
1 reply 0 retweets 1 like -
Replying to @ManishEarth @yoshuawuyts
It's often the first frame (or in the case of unwrap, the second frame), but not always. (There's an rfc for implicit caller location that makes this somewhat nicer for the semi-common case)
1 reply 0 retweets 0 likes -
Replying to @ManishEarth
Oh haha, yeah I don't disagree. Guess I should've been more specific. Currently we have a known TLS bug in a program. On invalid access instead of just panicking it'd be wild if we could track which thread failed, and show the line of code where the thread was spawned.
1 reply 0 retweets 1 like -
Replying to @yoshuawuyts @ManishEarth
I'm suspecting there might be more cases like these around stdlib. For example locks is another I'm curious about. But just in general if we could log the source lines corresponding to the failure I think we could really make some leaps.
1 reply 0 retweets 1 like -
Replying to @yoshuawuyts
Ah tracking threads is possible. When you spawn threads you can name them, fwiw, and that shows up in the backtrace.
2 replies 0 retweets 2 likes -
Replying to @ManishEarth @yoshuawuyts
But we *do* log source lines corresponding to the failures, that's what the backtrace is :)
1 reply 0 retweets 1 like -
Replying to @ManishEarth @yoshuawuyts
mutex/etc could have a debug mode thing that stores the location of the last backtrace they were locked from, though
1 reply 0 retweets 1 like
Yeah, stuff like this is exactly what I hoped we could do! :D
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.