Re:Why should I have written ZeroMQ in C, not C++ (2012)
by int_19h on Thursday December 13, 2018 @05:52AM
(#18671354)
This is an API design issue. The proper solution is to provide two versions of malloc or equivalent - one that doesn't have any error code, and simply panics on failure to allocate, and another that provides a way to recover. A typical app would then mostly use the first version, and very occasionally the second when it anticipates that allocation might be so large that it could fail even in a healthy environment (e.g. loading an entire file into memory).
[ Parent
| on HN ]
Re:Why should I have written ZeroMQ in C, not C++ (2012)
by mytherin on Thursday December 13, 2018 @10:42AM
(#18673074)
Panicing is not handling anything, it is just crashing the program. Unless you can catch the panic, in which case it's just another name for an exception. Not handling failed allocations except for on large allocations is just asking for rare crashes when one of the "unlikely to fail" allocations fails. Neither of these solve the problem in a robust way. Handling this properly is a language design issue. This is just applying a band-aid.
Re:Why should I have written ZeroMQ in C, not C++ (2012)
by int_19h on Thursday December 13, 2018 @05:02PM
(#18676542)
This is just recognizing the status quo. Pretty much no desktop or mobile or web software is handling "unlikely to fail" allocations. And how exactly do you expect them to handle it? If, say, it's a desktop app that's rendering a widget, and as part of that it needs to allocate a string, and that fails - how does it recover?
Panic on OOM is perfectly reasonable for most.
And yes, panics shouldn't be catchable. That's the whole point.