Sebb, On 10/3/13 8:06 AM, sebb wrote: > The problem is that bugs that reveal themselves as JVM crashes are > much harder to debug.
+1 This is exactly the point I was arguing. When we get a JVM crash report, the stack dump could be completely different depending upon which architecture, kernel, compiler, optimization flags, etc. that were used when compiling and/or running the library. Converting SIGSEGV into an exception gives us a lot of freedom to publish tons of useful information when reporting errors to the user. I'd rather get a report from a user that says something like "here is my stack trace and error message, complete with name of variable that was NULL and line of source code" rather than "here's my JVM crash report, sorry I didn't get a core file, I'm having trouble reproducing the error" (which is essentially what all currently-open JVM-crash error reports look like in BZ for tcnative). >> We can add compile time '#if defined(MAINTAINER_MODE) ... #endif' checks >> for easier debugging at development, > > Any crashes that occur in a released version of TC are likely to be > fairly rare, otherwise they would be detected in testing. > So the MAINTAINER_MODE is not likely to be much use after the initial > shakedown period. > Unless the debugging checks are expensive, why not leave them in? Obviously given my previous comments, I agree with this. If the MAINTAINER had an exhaustive set of unit tests, there would be no error reports, right? ;) I argue that MAINTAINER_MODE is exactly the opposite of what you want: you want real users to have this information precisely because they are *not* programmers (at least not C programmers). -chris
signature.asc
Description: OpenPGP digital signature
