if business logic assumes a set of preconditions before a particular piece of code that the language/runtime/os satisfies… then it’s an immediate assert. Any kind of IO, memory creation and OS operations fall into this carefory.
However if the business logic assumes something in its own domain and that assumption does not hold then its better to handle that instead of crashing. Ex. being you expect a queue to have at least one element in some pipeline and if it is empty then return saying nothing to be done.
Edit: don’t assert/crash if your application is single process multithreaded unless you want your friend from accounting asking you why their stock ticker crashed just when they clicked a button in the coffee shop module of your app. Use some thread exit mechanism.
My understanding so far is:
if business logic assumes a set of preconditions before a particular piece of code that the language/runtime/os satisfies… then it’s an immediate assert. Any kind of IO, memory creation and OS operations fall into this carefory.
However if the business logic assumes something in its own domain and that assumption does not hold then its better to handle that instead of crashing. Ex. being you expect a queue to have at least one element in some pipeline and if it is empty then return saying nothing to be done.
Edit: don’t assert/crash if your application is single process multithreaded unless you want your friend from accounting asking you why their stock ticker crashed just when they clicked a button in the coffee shop module of your app. Use some thread exit mechanism.