# Storage Error recovery

**URL:** <https://forum.ada-lang.io/t/storage-error-recovery/4909>\
**Category:** General\
**Created:** [November 2, 2026, 11:50am UTC](https://forum.ada-lang.io/t/storage-error-recovery/4909 "2026-11-02T11:50:16Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![kevlar700](https://forum.ada-lang.io/user_avatar/forum.ada-lang.io/kevlar700/32/1118_2.png) [@kevlar700](https://forum.ada-lang.io/u/kevlar700)\
**Post date:** [November 2, 2026, 11:50am UTC](https://forum.ada-lang.io/t/storage-error-recovery/4909/1 "2026-11-02T11:50:16Z")

</div>

It seems logical atleast to me (perhaps not bothered with possibly because of exception propagation complexities) that upon storage error upon stack exhaustion then a local exception handler that simply returns and sets an existing out status should enable the application to continue.

For ARM cortex-m0 I end up in the hardfault handler which makes sense but for amd64 native I get the following which surprised me

\_\_gnat\_error\_handler at init.c:592

```ada
procedure Storage_Exception is
begin
   declare
     Storaflow : String (1 .. 214000000) := [others => ' '];
   begin
      -- this code won't be reached
      Storaflow (1) := '2';

   exception
        when Storage_Error =>
             return;
   end;

exception
     when Storage_Error =>
          return;
end;

```

Thoughts welcome. Note that the declare trick avoids propagation for constraint error exceptions which would normally not be caught by a local handler if in the procedures main declaration section but does not for storage\_error.

---

<div class="post-metadata">

**Author:** ![kevlar700](https://forum.ada-lang.io/user_avatar/forum.ada-lang.io/kevlar700/32/1118_2.png) [@kevlar700](https://forum.ada-lang.io/u/kevlar700)\
**Post date:** [November 2, 2026, 12:53pm UTC](https://forum.ada-lang.io/t/storage-error-recovery/4909/2 "2026-11-02T12:53:16Z")

</div>

I guess if light runtimes were part of the Ada standard then a small part of the exception propagation mechanism might have been used to return and restore the previous stack frame?

---

<div class="post-metadata">

**Author:** ![Irvise](https://forum.ada-lang.io/letter_avatar_proxy/v4/letter/i/7ba0ec/32.png) [@Irvise](https://forum.ada-lang.io/u/Irvise)\
**Post date:** [November 2, 2026, 8:23pm UTC](https://forum.ada-lang.io/t/storage-error-recovery/4909/3 "2026-11-02T20:23:33Z")

</div>

I do not know if I understood the issue, but I believe in embedded targets using the light runtime there is no exception propagation and flow. So anything that raises an exception it just goes directly to the last chance handler or similar. Maybe for x86 the runtime has some extra tricks that allows it to handle them better, but I am not sure about that.

Best regards,  
Fer

---

<div class="post-metadata">

**Author:** ![godunko](https://forum.ada-lang.io/user_avatar/forum.ada-lang.io/godunko/32/22_2.png) [@godunko](https://forum.ada-lang.io/u/godunko)\
**Post date:** [November 2, 2026, 9:07pm UTC](https://forum.ada-lang.io/t/storage-error-recovery/4909/4 "2026-11-02T21:07:13Z")

</div>

It is interesting corner case I suppose. Don’t think it is possible to make any assumption here. There are few ways to do stack checks inside GNAT compiler. Target might have hardware support for stack checks. All these should be connected to each other… and, finally, exception should be raised in subprogram’s code, not inside runtime.