13 ms·

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

by 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

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.