5 ms·

You can have a null pointer handler in C as well. But this is generally not a good idea. I find software that does not crash early and visibly but instead trie

You can have a null pointer handler in C as well. But this is generally not a good idea. I find software that does not crash early and visibly but instead tries continuing despite an obvious bug very brittle and often causing trouble because it can take a long time before operators notice the problem. If you accumulate enough bugs of this type, you get a mess that "kinda works" but is full of surprises.

mcculley 4y ago
Yeah, I implemented an “atcrash” handler as a library which I embedded into multiple projects. But it was only so I could walk the stack, dump a stack trace into the terminal, and tell the user, “Please email this to the developer.” And then as cleanly as possible shut down the process. In C, as you say, not much else can be safely done.
- pkolaczk 4y ago
  In Java if you encountered a null pointer exception or out of bounds error at the global level, there is also no guarantee you can safely continue, and dumping the stack and terminating is the only sensible option. Sure, the JVM is ok, but your app state might be already corrupt.
  - mcculley 4y ago
    This has not been my experience at all. The JVM is not corrupted by a NPE or out of bounds access unless you are using native code. For example, I worked on a large X-Windows/Motif application with many developers. If some library dereferences a null pointer, it is game over. Kill the app. In a Java Swing app we built for a similar use case, we just trap the exception in the AWT event dispatcher, log it, and keep going. Yes, sometimes an exception has ruined the global state in some catastrophic way, but this is rare. We can keep running and debugging without restarting the whole app. Another example is a web app: Any exception that bubbles up to the main request handler loop is likely (in our architecture) to happen before any change is made to the persistent store. Log it and handle another request. This makes debugging a lot easier than restarting the whole app.
    - LaGrange 4y ago
      > This has not been my experience at all. This has been my experience with software written in Java by developers who think it was not their experience. > In a Java Swing app we built for a similar use case ...oh no. I actually tend to associate Swing UI with weird, undefined behaviors, and whenever I'd look under the hood, it would nearly _always_ be due to them trying to swallow runtime exceptions. Pure hubris, as far as I'm concerned. > Another example is a web app: Any exception that bubbles up to the main request handler loop is likely (in our architecture) to happen before any change is made to the persistent store. Log it and handle another request. Please, please, _PLEASE_ just crash the server. The OS will handle it, it will be OK, and systemd will even do the right thing and give up if your thing crashes _persistently_, including all the fancy stuff like keeping track of how often it crashes. I've done too much cleaning up after overly-confident superstar architects, your examples just brings painful memories. I beg you stop trying to be clever and just log the error and crash the app.
      - icedchai 4y ago
        There is some wisdom to what you say. I've experienced some Java apps that basically enter an exception/logging loop, quickly filling the system with gigs of logs full of 100 line stack traces. Eventually someone is alerted and has to clear the logs and kill -9 the app.
      - mcculley 4y ago
        I have the logs from my deployed apps. I know exactly how many times my users are getting those exceptions. We use those logs to fix the bugs and improve our apps. You seem to have a lot of opinions about my apps from your own unfortunate experiences. Hubris is a word that brings to mind.
        LaGrange 4y ago
        You do realize that “I have logs from my deployed desktop apps” only makes things sound worse? And if it’s professional environment - that creates _powerful_ biases. Essentially, I’ve seen apps with developers acting _exactly_ like you, up to and including the line about logs. You might be the one exception - but somehow I doubt it, and I certainly won’t trust your word on it. Automatically logging desktop activity makes me trust you less, if anything. In particular, I don’t believe you prioritize issues the way your users do. That would, literally, be a first.
kaba0 4y ago
Depends whether your “null pointer” is truly zero, or some random value that was not initialized.

mcculley 4y ago

Yeah, I implemented an “atcrash” handler as a library which I embedded into multiple projects. But it was only so I could walk the stack, dump a stack trace into the terminal, and tell the user, “Please email this to the developer.” And then as cleanly as possible shut down the process. In C, as you say, not much else can be safely done.

pkolaczk 4y ago
In Java if you encountered a null pointer exception or out of bounds error at the global level, there is also no guarantee you can safely continue, and dumping the stack and terminating is the only sensible option. Sure, the JVM is ok, but your app state might be already corrupt.
- mcculley 4y ago
  This has not been my experience at all. The JVM is not corrupted by a NPE or out of bounds access unless you are using native code. For example, I worked on a large X-Windows/Motif application with many developers. If some library dereferences a null pointer, it is game over. Kill the app. In a Java Swing app we built for a similar use case, we just trap the exception in the AWT event dispatcher, log it, and keep going. Yes, sometimes an exception has ruined the global state in some catastrophic way, but this is rare. We can keep running and debugging without restarting the whole app. Another example is a web app: Any exception that bubbles up to the main request handler loop is likely (in our architecture) to happen before any change is made to the persistent store. Log it and handle another request. This makes debugging a lot easier than restarting the whole app.
  - LaGrange 4y ago
    > This has not been my experience at all. This has been my experience with software written in Java by developers who think it was not their experience. > In a Java Swing app we built for a similar use case ...oh no. I actually tend to associate Swing UI with weird, undefined behaviors, and whenever I'd look under the hood, it would nearly _always_ be due to them trying to swallow runtime exceptions. Pure hubris, as far as I'm concerned. > Another example is a web app: Any exception that bubbles up to the main request handler loop is likely (in our architecture) to happen before any change is made to the persistent store. Log it and handle another request. Please, please, _PLEASE_ just crash the server. The OS will handle it, it will be OK, and systemd will even do the right thing and give up if your thing crashes _persistently_, including all the fancy stuff like keeping track of how often it crashes. I've done too much cleaning up after overly-confident superstar architects, your examples just brings painful memories. I beg you stop trying to be clever and just log the error and crash the app.
    - icedchai 4y ago
      There is some wisdom to what you say. I've experienced some Java apps that basically enter an exception/logging loop, quickly filling the system with gigs of logs full of 100 line stack traces. Eventually someone is alerted and has to clear the logs and kill -9 the app.
    - mcculley 4y ago
      I have the logs from my deployed apps. I know exactly how many times my users are getting those exceptions. We use those logs to fix the bugs and improve our apps. You seem to have a lot of opinions about my apps from your own unfortunate experiences. Hubris is a word that brings to mind.
      - LaGrange 4y ago
        You do realize that “I have logs from my deployed desktop apps” only makes things sound worse? And if it’s professional environment - that creates _powerful_ biases. Essentially, I’ve seen apps with developers acting _exactly_ like you, up to and including the line about logs. You might be the one exception - but somehow I doubt it, and I certainly won’t trust your word on it. Automatically logging desktop activity makes me trust you less, if anything. In particular, I don’t believe you prioritize issues the way your users do. That would, literally, be a first.

kaba0 4y ago

Depends whether your “null pointer” is truly zero, or some random value that was not initialized.