3 ms·

What is your definition of graceful in this case? Presumably there was a “business need” for the allocation and the software isn’t just allocating for fun. An

What is your definition of graceful in this case? Presumably there was a “business need” for the allocation and the software isn’t just allocating for fun. An allocation failure is a hard fault, it’s not possible to honor the business need so something expected to happen cannot happen. The program could segfault when the null pointer returned is written to, that is kind of crappy. It could report the error “hey we are out of memory and couldn’t do xyz” or better “hey we are out of memory and couldn’t do xyz, this is probably because of abc, maybe you can adjust the tuning.” Or it could be a completely temporal thing, maybe you flush some caches or something to free up some memory and reschedule the work. I don’t know, maybe this is old school, but yes you should put a check on every toolbar allocation for two reason: one you can gracefully report why your app isn’t doing it’s job and two it is a very very slippery slope when you start ignoring those errors as a matter of practice

Crinus 7y ago
> It could report the error “hey we are out of memory and couldn’t do xyz” or better “hey we are out of memory and couldn’t do xyz, this is probably because of abc, maybe you can adjust the tuning.” What if you cannot do that report because the reporting itself needs memory that can fail? > but yes you should put a check on every toolbar allocation for two reason: one you can gracefully report why your app isn’t doing it’s job This is a reason to put checks in every toolbar allocation, but on the other hand there is also a reason to not do that: you are trying to catch a case that will only happen at a 0.00001% of the time yet to do that you are making the codebase more complex which will affect working with it 100% of the time. Unless you are working in something like a medical or nuclear device, it is not worth to bother with such things. Even then when it comes to high risk programs relying on the programmer doing things right outside the core functionality is probably (i haven't worked on such projects myself so i'm guessing here) not a good idea and instead you should compartmentalize (e.g. the core functionality is running as a separate process from the UI and if the UI crashes, a watchdog restarts the UI process). But that is my guess here, i mainly have common end user/consumer applications in mind.
- 95014_refugee 7y ago
  > Unless you are working in something like a medical or nuclear device, it is not worth to bother with such things. Where "something like a medical or nuclear device" implies a piece of software that is expected to work correctly. In other words, you should always ensure that failures resulting from malloc(3) returning an error (and all other errors) are suitably contained.
  - Crinus 7y ago
    No, i did not implied that, please do not put words in my mouth. My implication was software that if it fails it will kill people. Otherwise if a program crashes because of a situation happens once every 100000000 runs, not only is worthless to worry about it, it actually is preferable to not do that as to keep the codebase clean and hence easier to maintain for bugs that actually do affect people.
    - mark-r 7y ago
      Keeping the codebase clean is why I prefer that allocation errors throw an exception rather than returning NULL.
      - cesarb 7y ago
        But then you have to worry about exception safety on every code which might call an allocating function, making the code more complex. This is worse on C++ where even innocent-looking code could be allocating memory in the middle of an operation (for instance, by calling a copy constructor which allocates).
- fwip 7y ago
  > What if you cannot do that report because the reporting itself needs memory that can fail? Allocate and reserve error-reporting memory early. For example, your ErrorReporter instance is initialized at start-up, and doesn't call malloc() when you make a report.
- 7y ago

Crinus 7y ago

> It could report the error “hey we are out of memory and couldn’t do xyz” or better “hey we are out of memory and couldn’t do xyz, this is probably because of abc, maybe you can adjust the tuning.” What if you cannot do that report because the reporting itself needs memory that can fail? > but yes you should put a check on every toolbar allocation for two reason: one you can gracefully report why your app isn’t doing it’s job This is a reason to put checks in every toolbar allocation, but on the other hand there is also a reason to not do that: you are trying to catch a case that will only happen at a 0.00001% of the time yet to do that you are making the codebase more complex which will affect working with it 100% of the time. Unless you are working in something like a medical or nuclear device, it is not worth to bother with such things. Even then when it comes to high risk programs relying on the programmer doing things right outside the core functionality is probably (i haven't worked on such projects myself so i'm guessing here) not a good idea and instead you should compartmentalize (e.g. the core functionality is running as a separate process from the UI and if the UI crashes, a watchdog restarts the UI process). But that is my guess here, i mainly have common end user/consumer applications in mind.

95014_refugee 7y ago
> Unless you are working in something like a medical or nuclear device, it is not worth to bother with such things. Where "something like a medical or nuclear device" implies a piece of software that is expected to work correctly. In other words, you should always ensure that failures resulting from malloc(3) returning an error (and all other errors) are suitably contained.
- Crinus 7y ago
  No, i did not implied that, please do not put words in my mouth. My implication was software that if it fails it will kill people. Otherwise if a program crashes because of a situation happens once every 100000000 runs, not only is worthless to worry about it, it actually is preferable to not do that as to keep the codebase clean and hence easier to maintain for bugs that actually do affect people.
  - mark-r 7y ago
    Keeping the codebase clean is why I prefer that allocation errors throw an exception rather than returning NULL.
    - cesarb 7y ago
      But then you have to worry about exception safety on every code which might call an allocating function, making the code more complex. This is worse on C++ where even innocent-looking code could be allocating memory in the middle of an operation (for instance, by calling a copy constructor which allocates).
fwip 7y ago
> What if you cannot do that report because the reporting itself needs memory that can fail? Allocate and reserve error-reporting memory early. For example, your ErrorReporter instance is initialized at start-up, and doesn't call malloc() when you make a report.
7y ago