4 ms·

There is no such thing as an "orthogonal problem" here, both things connect. That's why you (a) want to have your processes staying alive in about any software

by fnl 9y ago

There is no such thing as an "orthogonal problem" here, both things connect. That's why you (a) want to have your processes staying alive in about any software as long as possible (hence invalidating your argument for #1), and (b) as I clearly mentioned, you do need to report such unexpected errors to the developer of the program, to avoid that they get swept under the rug. But handling cases from #1 as you described is nonviable in (virtually) all cases (except as described: if the error prevents the binary from completing that single job it was run on). Just imagine any of the programs you are running on your machine right now would just crash because they are not resilient to an off-by-one fencing error or whatever other bug (and there will be issues, even in your three-liners). I bet you'd be pretty pissed off if your programs would crash on you every other day or so...

ensiferum 9y ago
You have it so backwards... Whats the point of a program producing incorrect results? Whats the value of that? Let's have an example. Person& findPerson(key_t key) {...} Now this is a core function, the basic precondition of the function is that the key is valid and exists. The function is called with a key that doesn't meet the precondition. A programmer who wrote the client code has made a bug. How do you deal with this situation? Throw and exception? Change the signature and return an error code + person? Great, now you've turned a bug into an "error", masking the actual problem. Then what does the calling code do? How is it prepared to handle "bugs". What does the logic to deal with bugs look like? Then you write bugs in your code trying to deal with bugs? Alternatively (I know some big orgs do this..) they put in a log and then return some "default object" and pretend there was no problem. Now how's the calling codes computation going to go, it's given bogus data to deal with. Bottom line, I want my programs to be bug free and correct. I don't want to even try to clutter my code with trying to write logic to deal with bugs. What I want on every bug is clean termination, program state and stack trace. It makes it very easy to fix the bug thus actually improving my software quality. I'm happy to know that my software actually has very few bugs. I know that you might think that it's inconvenient for the user to have his software abort. But if the software produces corrupt results then whats the value of that? Even worse, the user can think that results are correct even though it's garbage. Seriously, going back to the example. iF the precondition is validated you abort. Your developers can easily fix the offending code, release a new version of the software and your system is just that much better. If you incorporate this methodology from the start of the project you can greatly improve your quality in general.
- fnl 9y ago
  For your core argument to hold, terminating a process would have to lead to software with fewer bugs than software that that can report and recover from bugs. I don't see how that would be the case. Second, you did not address my main argument, that anybody (including you, your code's customers/users, etc.) would be very annoyed if our software were to crash on every remaining issue in our programs. And that argument goes as far as that the behavior you suggest could lead to us not using that service, software, OS, or even computers as a whole.
  - AstralStorm 9y ago
    Generally terminating is a "very bad" behaviour. If you do not want it in production, better invest in ACID semantics for your application state and restore it on crash. Much more elegant than wrong behaviour, much more user friendly. This is typical for modern mobile applications which are supposed to be killable and restartable at any time. In other words, make application idempotent for any start condition.
  - ensiferum 9y ago
    I think my customers would be quite annoyed if they were served junk data. The only result they care about is getting the correct output. And I'm not saying it will necessarily lead to fewer bugs. What I'm really saying is that allows one to debug identify and fix the bugs easily, or easier than some other alternatives such as printing some error message to some log and then (possibly) continuing in UB land while silently corrupting state and then finally causing some new weird error (or crash if you're lucky). So what I'm really advocating that dumping the core gives you two benefits: - simplifies your code when you don't try to write logic to deal with broken logic itself. - simplifies bug detection, analysis and fixing. Together these two translate to more correct programs assuming that you actually go and fix the problems Also you didn't answer my question. I'd like to see what kind of kludges you'd recommend.

by fnl 9y ago

ensiferum 9y ago

You have it so backwards... Whats the point of a program producing incorrect results? Whats the value of that? Let's have an example. Person& findPerson(key_t key) {...} Now this is a core function, the basic precondition of the function is that the key is valid and exists. The function is called with a key that doesn't meet the precondition. A programmer who wrote the client code has made a bug. How do you deal with this situation? Throw and exception? Change the signature and return an error code + person? Great, now you've turned a bug into an "error", masking the actual problem. Then what does the calling code do? How is it prepared to handle "bugs". What does the logic to deal with bugs look like? Then you write bugs in your code trying to deal with bugs? Alternatively (I know some big orgs do this..) they put in a log and then return some "default object" and pretend there was no problem. Now how's the calling codes computation going to go, it's given bogus data to deal with. Bottom line, I want my programs to be bug free and correct. I don't want to even try to clutter my code with trying to write logic to deal with bugs. What I want on every bug is clean termination, program state and stack trace. It makes it very easy to fix the bug thus actually improving my software quality. I'm happy to know that my software actually has very few bugs. I know that you might think that it's inconvenient for the user to have his software abort. But if the software produces corrupt results then whats the value of that? Even worse, the user can think that results are correct even though it's garbage. Seriously, going back to the example. iF the precondition is validated you abort. Your developers can easily fix the offending code, release a new version of the software and your system is just that much better. If you incorporate this methodology from the start of the project you can greatly improve your quality in general.

fnl 9y ago
For your core argument to hold, terminating a process would have to lead to software with fewer bugs than software that that can report and recover from bugs. I don't see how that would be the case. Second, you did not address my main argument, that anybody (including you, your code's customers/users, etc.) would be very annoyed if our software were to crash on every remaining issue in our programs. And that argument goes as far as that the behavior you suggest could lead to us not using that service, software, OS, or even computers as a whole.
- AstralStorm 9y ago
  Generally terminating is a "very bad" behaviour. If you do not want it in production, better invest in ACID semantics for your application state and restore it on crash. Much more elegant than wrong behaviour, much more user friendly. This is typical for modern mobile applications which are supposed to be killable and restartable at any time. In other words, make application idempotent for any start condition.
- ensiferum 9y ago
  I think my customers would be quite annoyed if they were served junk data. The only result they care about is getting the correct output. And I'm not saying it will necessarily lead to fewer bugs. What I'm really saying is that allows one to debug identify and fix the bugs easily, or easier than some other alternatives such as printing some error message to some log and then (possibly) continuing in UB land while silently corrupting state and then finally causing some new weird error (or crash if you're lucky). So what I'm really advocating that dumping the core gives you two benefits: - simplifies your code when you don't try to write logic to deal with broken logic itself. - simplifies bug detection, analysis and fixing. Together these two translate to more correct programs assuming that you actually go and fix the problems Also you didn't answer my question. I'd like to see what kind of kludges you'd recommend.