When a runtime error occurs with a program in language likes C or C++ using GCC/G++, it just crashes the process. When it occurs with a program in language like Rust or Golang, a detailed error message will be given.
$\begingroup$
$\endgroup$
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
It's a matter of design.
When a program runs (whether it is compiled or interpreted, it does not really matter), it is executed in an enveloping runtime environment. When an error occurs, the enveloping runtime environment may or may not be equipped with figuring out how exactly the program got to the error.
Two possible design choices are:
Keep the runtime environment minimal and do not bother printing out nice error messages when the program crashes. If the programmer wants to figure out what happened, they can run a debugger.
Be friendly to the programmer and equip the program with tracebacks and printing of informative error messages. This makes the runtime environment larger, and possibly incurs a small cost in efficiency and memory conspumption, but it also shortens development time, as one can often see directly from the error message what needs to be fixed.
The first choice made more sense decades ago, when computers had little memory and CPU time was more valuable than programmer time. The second choice makes more sense nowadays, when development time is precious and it usually does not matter if an executable contains extra code for handling errors.
answered Feb 21, 2022 at 9:29
$\begingroup$
$\endgroup$
If you compile with debugging information and have a debugger installed, the debugger will show you the line that caused the crash in context, the stack, the status of other threads, the values of local and global variables and any heap objects they may point to, etc. You may be able to set a breakpoint before the error location, restart the process, and single-step to see how the error comes about. It's much more useful than a traceback.
Printing a traceback on failure amounts to copying a limited subset of the debugger into each compiled executable. It's possible, but there's no tradition of doing it in the C and C++ world. It's assumed that if you know how to read tracebacks, you'll use the debugger.
C and C++ implementations often do show error messages (without tracebacks) for assertion failures, and sometimes for some other errors like division by zero, if there's no debugger to handle them.
