4 ms·
I don't understand the mindset you have to be in, in order to prefer the second error example to the first
by jcelerier 6y ago
I don't understand the mindset you have to be in, in order to prefer the second error example to the first
- q3k 6y agoProduction outage at 2am.
- Measter 6y agoThe 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.
- jcelerier 6y agohaving worked with both cases I'd take the backtrace every single day
- Measter 6y agoBut 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.
- jcelerier 6y agoI 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
- Sohcahtoa82 6y agoAll 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?
- steveklabnik 6y agoThe majority of those lines are including the function name, the file name, and the line number.