> What exactly is the difference between a panic and an exception?
By my understanding it's the difference between what you want to do and how you do it. Panicking is the what ("Something went wrong! Halt operation!"), exceptions are one of the hows (unwind). Aborting is the other one.
That's one of the reasons panics should not be used for normal errors - there's no general guarantee you can catch them. Granted, that's more of a restriction on library developers, since they don't control the panicking mode.
> C++ for its part is not burdened with that mistake. There is remarkable attention paid in the STL to the possibility of an out-of-memory condition and allowing a complete recovery from the same. This is a useful feature that systems software often requires.
At least by my impression OOM in the STL is generally handled via std::bad_alloc. While that's something at least, I'm not sure I'd call that "remarkable attention" on its own, especially since I don't think it's that uncommon for systems software to be compiled with -fno-exceptions. I'm not sure using alternative allocators would help in this case either, since I don't think the way APIs are defined allow you to surface allocation failures in any way other than exceptions (e.g., what happens on OOM during std::vector::push_back?).
To me, "remarkable attention" would be more akin to what Zig does with allocator parameters and surfacing allocation errors in the API.
By my understanding it's the difference between what you want to do and how you do it. Panicking is the what ("Something went wrong! Halt operation!"), exceptions are one of the hows (unwind). Aborting is the other one.
That's one of the reasons panics should not be used for normal errors - there's no general guarantee you can catch them. Granted, that's more of a restriction on library developers, since they don't control the panicking mode.
> C++ for its part is not burdened with that mistake. There is remarkable attention paid in the STL to the possibility of an out-of-memory condition and allowing a complete recovery from the same. This is a useful feature that systems software often requires.
At least by my impression OOM in the STL is generally handled via std::bad_alloc. While that's something at least, I'm not sure I'd call that "remarkable attention" on its own, especially since I don't think it's that uncommon for systems software to be compiled with -fno-exceptions. I'm not sure using alternative allocators would help in this case either, since I don't think the way APIs are defined allow you to surface allocation failures in any way other than exceptions (e.g., what happens on OOM during std::vector::push_back?).
To me, "remarkable attention" would be more akin to what Zig does with allocator parameters and surfacing allocation errors in the API.