I suggest raising the question on the forum for the board package you have used. Visual Micro and the Arduino IDE read the compiler instructions from the package then run the commands specified by those instructions. That means that the board package authors decide how things work.

If the authors provide switches then we can tell you how to make use of them.

Thanks for the update and link to the ticket.

The options can be set in the Project Properties (vMicro > Project Properties) under the Configuration Extra Flags.

Thanks for the update.

The patterns in the STM32 board package already include the "-fno-exceptions" which will be overriding your entries in the project properties.

Assuming you are using the v2.9.0 version of the STMicroelectronics board package:
1) Remove the entries in the Project Properties box (to avoid confusion as they are obsolete in this scenario)
2) Add a Local Board.txt to the project (vMicro > Add Code > Add Local Board.txt)
3) Paste in the contents of the attached file
4) Restart Visual Studio and build and upload again

This is just overriding the "compiler.cpp.flags" pattern which can be seen in the output when vMicro > Compiler > Show Build Properties is enabled.

If you are using a different board package version, or if you need this to be a system wide change let us know (there is an alternative way to override this using the platform.local.txt file which is injected into the board package folder).

Hi Simon,

to avoid the quite complicated steps from your 

Reply #5 - Today at 4:54pm 

I suggest that you pass the '-fexceptions' flag to the compilation of the libraries for new etc. 

ESP32 projects already work this way. They throw an exception for 

std::vector<int> v;
int too_much_push_backs()
{
  Serial.printf("Start too_much_push_backs() \n" );
  while (true) // leave at an exception
  {            //        from push_back
    v.push_back(1);
    if (v.size() % 1000 == 0)
      Serial.printf("  v.size()=%d \n", v.size());
  }
} 

I consider it highly counterintuitive to turn exception handling on, but to get it only for a part of the code, with the final effect, that I don't get it at all for e.g. push_back.

Thanks
Richard

Hi Simon,

attached are the build properties for an
STM32-F303RE
Raspberry RP-2350
ESP32

Best
Richard

Thanks for the logs and the updates.

The behaviour differs between these boards due to the very different architectures and SDKs which are used in the toolchains production, and the flags enabled for their respective compilers, as well as it being an embedded environment.

I believe exceptions are not always thrown or are disabled at compile time (in the case of STM32) due to limited resources and increased latency when handling exceptions.  It is also important to note the "Standard C/C++" libraries are not complete on microcontrollers due to the code space and resources availablle.

RP2350
On the RP2350, it never throws the bad_alloc() exception, which digging into the "new" function using a Hardware Debugger seems to be due to the PicoSDK Build (used within the core) having PICO_CXX_ENABLE_EXCEPTIONS set to 0.  There also appears to be some compiler optimization interfering with the null pointer, which is improved with the -f-no-delete-null-pointer-checks compiler flag (which can be specified in the Project Properties in vMicro).

With the -f-no-delete-null-pointer-checks flag added only one instance of p=0 is shown (so exits at the right time), but no bad_alloc exception is thrown, however the while() loop in your code will exit as p == nullptr.

This can then be caught in an if statement, and manually thrown as bad_alloc if desired, as p == 0 || p == nullptr do mean the allocation failed.  You could implement this approach as an overridden new handler if desired.

STM32
Using an STM32 Nucleo F103RB (I dont have your exact model), and using the -fexceptions flag at compile time the too_much_push_backs() example given, does generate an exception, however this then jumps to the Default_Handler, which is defined as an infinite loop.  The only way to see futher information about an uncaught exception is using a debug probe, which some boards have builtin and can be used within Visual Micro.

Current Conclusion
The board package authors are the best place to get detail about this depth of the implementation of the GNU C/C++ specification embedded in their Arduino board packages for each architecture, and may be different to the standard C/C++ implementations seen on desktops etc... where the full standard can be adhered to.

The override can be applied in the Local Board.txt for each project (vMicro only).

To override the entire board package (for all projects using it in vMicro + ArduinoIDE), you would need to go to the folder where the current package is installed and create a platform.local.txt file, with the overridden pattern in.

Normally this would be under "%LOCALAPPDATA%\Arduino15\packages\rp2040\hardware\rp2040\4.0.2" for v4.0.2 of the RP2040/2350 Board Package (but there are various ways to reconfigure the root Arduino15 folder so its not a gaurentee).

If unsure you can enable "vMicro" > "Compiler" > "Show Build Properties", then after performing a build review the value of "runtime.platform.path".

The downside to platform.local.txt is that when the board package is updated, the file will be lost and needs to be added back in again.

You can edit the platform.txt directly, or add a seperate platform.local.txt next to it (so you can isolate your changes into a single file).

This will perform the same changes as the local board.txt did in the project (after a VS Restart), but for all consumers of the package.

Apologies for the bad example of the RP2040, there is a menu item "C++ Exceptions" which controls the behaviour for that board package.

The STM32 would need the patterns amending (and copying to platform.local.txt if using that), anywhere that -fno-exceptions appears (and any other patterns you want to enable it for e.g. compiler.c.flags for C code).

For the RP2350 there is no need for any manual overrides, as the menu option does this for you (shown in the below image).  Once selected if you build the project again with vMicro > Compiler > Verbose enabled, you will see the -fexceptions flags in the compiler commands.

Whether this has the desired effect on the vector memory overflow is best reported to the board package author, and as stated previously for the RP2350 I believe it could be related to the PicoSDK in use in that board package, which Visual Micro has no control over.

Using a Hardware Debugger is the best way to determine the root cause of an exception which causes a hard failure in Micro Controllers, and for the RP2350 there are a few options available:
https://www.visualmicro.com/page/RasPiPico-Debugging.aspx

The overrides needed may differ for each board package, and version so there is no one-size-fits-all solution to compiler flags across architectures/time.