Alternate noexcept option

[rpavlik]

Initial work on an alternate way to avoid throwing exceptions, but also avoid terminating

• Add exception data type
• More work on ExceptionData
• More exception data.
• Work on adding noexcept path
• Add more no-exception options

[bialpio]

Nitpick: I think this approach is error-prone - IMO it should be OK to just have a std::string member that'll get populated when some exception is being thrown. For one, IDK if there's a way to enforce that setFromStaticMessage() is actually called with a string literal. Another problem is that this class needs to correctly handle each of the 3 cases (static message, dynamic message, exception object) and I think dynamicMessage is not currently handled correctly in throwException() & in getMessage().

[rpavlik]

yeah, dynamic message was kind of half-added. I wasn't 100% sure what class of exceptions we should be robust to, so I was trying to avoid non-"noexcept" functions including the string constructor if possible.

(TBH I rarely work with exceptions disabled, so I have no real good mental model of how C++ works without that functionality.)

[bialpio]

Hmm, I didn't think of that... I see that std::runtime_error's ctors aren't noexcept so IDK how important it is to stick to such methods here. I think they also will have to make a copy of the data for the same reasons we'd have to copy it here (i.e. const char* doesn't guarantee that the ptr will be forever valid)? libc++'s implementation seems to introduce refcounting here as well, but in the end there's going to be a new + memcpy (IIUC this is called from runtime_error's ctor). It may be that std::string ctor and std::runtime_error ctor cannot be noexcept because allocation can always throw, so maybe we don't have to worry about this?