@malkia, jerf, smeterdemon bluGill Ok first thing first. Like I said for some specicial resource constrained system abort() can be a viable solution, or if yo

@malkia, jerf, smeterdemon bluGill Ok first thing first. Like I said for some specicial resource constrained system abort() can be a viable solution, or if you just don't want to deal with any resource allocation failures. In general though if you have a std::vector and a push_back throws bad_alloc, that bad_alloc really only pertains to that particular vector using that particular allocator. If you assume that a bad_alloc coming from anywhere indicates some kind of system/process wide condition you're assuming too much. UNLESS you've designed the system, i.e. in this case the allocators and such and know this assumption to be true, otherwise no. Additionally consider a case where your code is for example reading some data off a disk in a loop and the Nth iteration and push_back throws, the stack is unwound, the vector is destroyed and the memory it consumed before is released. In a "normal" application the bad_alloc can propagate up the stack until it's handled by whatever strategy that the application uses for general resource failures. The two takeaways here are that bad_alloc doesn't really indicate any system wide condition (unless you know that it does), so don't assume such. Secondly bad_alloc is just like any other resource allocation failure. If your application aborts() when it cannot open a socket, that's fine. But if it doesn't, then why would it abort on memory allocation failure? And I really want to stress here that bad_alloc doesn't mean same as OOM for example from the kernel's perspective. It really only pertains to a particular allocator, UNLESS you KNOW otherwise.