Am Sat, 04 Oct 2014 01:43:40 -0700 schrieb Walter Bright <[email protected]>:
> Would you agree that every time DMD reports a syntax error in user code, it > should also include a stack trace of the DMD source code to where in DMD it > reported the error? Of course not. DMD is a compiler and it is part of its normal operation to have sophisticated code to report syntax errors. I distinguish between "expected" exceptions and "unexpected" exceptions. Expected exceptions are those that occur due to validating user input or as part of handling documented error codes at the interface layer with external APIs. Unexpected exceptions are those we don't handle explicitly because we don't expect them. Maybe because we think that code wont throw, since the input had been validated or a bug in an external library or laziness. A FileNotFoundException can be the expected result of an "open file" dialog with the user typing the name of a non-existent file or the unexpected result of loading a static asset with an index that is off-by-one (e.g. icon<idx>.bmp). In the case of DMD, syntax errors are *expected* as part of validating user input. And that's why it prints a single line that can be parsed by IDEs to jump the the source. Now to make things interesting, we also see *unexpected* exceptions in DMD: internal compiler errors. While expected exceptions are commonly handled with a simple message, unexpected exceptions are handled depending on application. In non-interactive applications like DMD they can all be AssertErrors that terminate the program. In interactive software like a video editor, someone might just have spent hours on editing and the user should be allowed to reason about the severity of the fault and decide to ignore the exception or quit the program. There are other solutions like logging and emailing the error to someone. The example above, about the off-by-one when reading an icon is a typical case of an exception that you would want to investigate with an exception stack trace, but keep the program running. -- Marco
