4 ms·
The author appears to be trying to use error messages in their own code to debug it which is a pretty weird way to use error messages. Error messages are for hu
by Veserv 6y ago
The author appears to be trying to use error messages in their own code to debug it which is a pretty weird way to use error messages. Error messages are for humans and users. If you are developing your own code you can just use a debugger to debug the problem.
Assuming they only had access to basic tools they could have just plopped down a breakpoint in the relevant error return from copy_from_process() and slowly walk up to discover their nullptr error pretty quickly without any code changes. If they had modern tools they could have just turned on tracing and then run backwards to figure that out and where the nullptr came from.
- iudqnolq 6y agoI've found the rust debugging experience to be very primative. When you say modern tools, are you describing rr? As far as I know that doesn't reliably integrate with rust?
- mathstuf 6y agoI've used gdb just fine on Rust code. Pretty printing isn't always as good, but if Rust is crashing, I'm probably down towards the syscall level anyways (or blowing the stack size as my last observed crashes were triggering).
- iudqnolq 6y agoI've had similar experiences. Inwas referring to the parent arguing that using Results and error enums to debug your own code is silly when you could just step backwards in a debugger. In my experience the rust debugging story isn't fluid enough that it's better than logging to debug most logic bugs.
- jiehong 6y agoIt could also just be a problem that appears in production, where there is no way to add breakpoints after the fact (even more so if this only occurs very rarely).