After 1.68.0 released, I found the annotation #[panic_handler], but I think it is very similar to #[global_allocator], it want to solve the problem of alloc globally, but it is often not flexible enough.
Just like now the alloc class has added A generics, such as Box<T, A>, Vec<T, A>, I think in the future, in order to solve the problem of possible panic of Box::new, there will be Box::try_new, Vec ::try_new and other methods.
Neither the global allocator nor the panic handler are obsolete, per se. They're not really for customization of your application behavior, but handing an unusual environment where the defaults don't work (or work well). In particular, panics can occur for many, many reasons, not just failed allocation. Even dividing by 0.
That said, I kind of would like the option to not have either, disabling parts of the standard library that use them (which would be quite a lot), but I'm not sure it's practical and simply using #![no_std] is good enough.
There is panic_immediate_abort…
Notice what is being stabilized here and what isn't:
a) #[panic_handler] has been stabilzed before and handels all sorts of panics, not only alloc related one.
b) A dedicated alloc panic handler (#[alloc_error_handler]) has not been stabilized. That would have been the global solution you are talking about.
c) Alloc failures are now guranteed to cause a panic. This removes the need to define such a global solution manually in most cases.
In some sense b) and c) combined are intended to actively discorage a global solution specifically to alloc, precisely because of the sentiment you mentioned. If you not only want to avoid alloc related panics, by using failable allocation methods, but also want to absolutly rule out panics, you likely want to settle things for all panics, not only alloc related ones.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.