BHoM_Engine: Reconsider stack trace extraction for events

[IsakNaslundBh]

Description:

Following up on #3522

Given the stack trace for versioning was shown to both take up an large amount of RAM, and also significantly slow down the versioning process due to the stack unwinding, worth considering if the stack trace always should be extracted for all events or not. Especially Notes and Warnings can for a lot of cases just be raised to pass information to users, and the stack trace will generally be of little use for that case.

For users in general the stack trace might not be that useful, as many people wont be able to use it to help deduce what the error is anyway, and generally, the messages should be enough to help deduce why something is not working.

I have two potential ideas for improving this:

Option 1
Could simply add a boolean input to all event methods (RecordError/Warning/Note/Event) like storeStackTrace or similar which simply controls whether the stack should be unwound and stored or not. For this I would default the boolean to false for notes and warnings, and true for errors and events.

Option 2
Could make it based on pre-compiler directives, and only store the stack when building in Debug mode, but not in release. This way developers building the code will have the stack trace available, but people running installers wont, and hence will get a nice little boost.

Personally would vote for Option 1 as it feels more flexible.

Happy with comments on this :)

@pawelbaran @adecler @alelom @peterjamesnugent @jamesramsden-bh

[pawelbaran]

Thanks for raising @IsakNaslundBh 👍 I'd go for option 1, option 2 would only work if one builds BHoM_Engine from source as far as I understand?

[IsakNaslundBh]

Thanks for raising @IsakNaslundBh 👍 I'd go for option 1, option 2 would only work if one builds BHoM_Engine from source as far as I understand?

For option 2 it would include the stack trace only if Debug build, so only remove it for Release builds. Do not really believe in this solution, just something I thought of in case we wanted to go down that route, as it would still always be there on developers machines, whilst people running installers would not get it.