The mindset is that an program output like this in the event of a user input error is not good:
Cup
60 skins in DB
104 drivers in DB
thread 'main' panicked at 'Could not find car folder or its skins: acrl_poorsche_911_gt3_cup_2017', src\main.rs:104:17
stack backtrace:
0: 0x7ff72a06deca - std::backtrace_rs::backtrace::dbghelp::trace
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\..\..\backtrace\src\backtrace\dbghelp.rs:98
1: 0x7ff72a06deca - std::backtrace_rs::backtrace::trace_unsynchronized
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\..\..\backtrace\src\backtrace\mod.rs:66
2: 0x7ff72a06deca - std::sys_common::backtrace::_print_fmt
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\sys_common\backtrace.rs:79
3: 0x7ff72a06deca - std::sys_common::backtrace::_print::{{impl}}::fmt
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\sys_common\backtrace.rs:58
4: 0x7ff729fb93bb - core::fmt::write
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\core\src\fmt\mod.rs:1080
5: 0x7ff72a06c9e8 - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\io\mod.rs:1516
6: 0x7ff72a06bd18 - std::sys_common::backtrace::_print
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\sys_common\backtrace.rs:61
7: 0x7ff72a06bd18 - std::sys_common::backtrace::print
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\sys_common\backtrace.rs:48
8: 0x7ff72a06bd18 - std::panicking::default_hook::{{closure}}
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:206
9: 0x7ff72a06bd18 - std::panicking::default_hook
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:227
10: 0x7ff72a06bd18 - std::panicking::rust_panic_with_hook
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:577
11: 0x7ff72a073ab5 - std::panicking::begin_panic_handler::{{closure}}
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:484
12: 0x7ff72a073a77 - std::sys_common::backtrace::__rust_end_short_backtrace<closure-0,!>
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\sys_common\backtrace.rs:153
13: 0x7ff72a073a1f - std::panicking::begin_panic_handler
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:483
14: 0x7ff72a0739e0 - std::panicking::begin_panic_fmt
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:437
15: 0x7ff729f3501e - __ImageBase
16: 0x7ff729f3f9eb - __ImageBase
17: 0x7ff729f51486 - main
18: 0x7ff729f40277 - main
19: 0x7ff72a0885f0 - invoke_main
at d:\agent\_work\63\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
20: 0x7ff72a0885f0 - __scrt_common_main_seh
at d:\agent\_work\63\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
21: 0x7ffeb18b7034 - BaseThreadInitThunk
22: 0x7ffeb1e9cec1 - RtlUserThreadStart
That stack track is completely worthless. It tells you literally nothing. Worse, is that while the actual problem is printed, it gets lost with the mess of noise after it. Whereas an error output like this is clearer:
Cup
60 skins in DB
104 drivers in DB
Error: Failed to verify series data
Caused by: Could not find car folder or its skins: acrl_poorsche_911_gt3_cup_2017
The core error is that a car or skin folder was missing, and that error caused verification to fail. That's what should be printed, because that's what is relevant.
All this tells me is that Rust gives crappy useless stack traces that include noise of functions handling the panic itself and the creation of the stack trace, and this has poisoned your view of stack traces.
Why can't Rust produce much more readable, concise, and useful stack traces like Python, that include the function name, file name, and line number of each step of the stack?
The only ones with line numbers are library code handling the panic. None of the actual user code has line numbers or even the file name, just a function name.
But that backtrace doesn't actually tell you what function the error occurred in. The function stack would be this (discarding everything outside of my code):
1: ImageData::verify_and_update - src\main.rs:104
2: run - src\main.rs:653
3: main - src\main.rs:673
That's why the backtrace is worthless here. It doesn't actually tell you where you were in the chain of function calls. In this case, it's relatively simple, so just knowing the line does help. But in a more complex application you could end up in a scenario where a function is called in multiple places, with different call stacks, and you don't know how you even got there because things were inlined and the backtrace doesn't tell you.
I don't know how rust's error libraries work but I definitely don't have this issue in C++ - the top of the backtrace is pretty much always where the error is
