support exception-free build

[alyssawilk]

We've slowly whittled down exceptions from the Envoy data plane but even with the work we've done on #14320 there are still some exceptions in the data plane, and it's hard for new users of Envoy to know where to use exceptions and where to use other error handling.

I'd like to move towards Envoy being able to build without exceptions entirely, primarily for envoyproxy/envoy-mobile#176 but also due to continued concerns in-house with performance and safety of exceptions.

I have a proof-of-concept "no exceptions" build of Envoy Mobile, which currently replaces "throw" with "throw or panic" in about 60 files (down from ~120, and envoy mobile panics on config parse fail in any case), and straight removal of catch macros. I'd like to

1. disallow new core code files from throwing exceptions (which we can add to iff necessary)
2. replace existing catch calls with CATCH_EXCEPTION_MAIN_THREAD{} which can compile out in no-exceptions build
3. slowly replace the throwEnvoyExceptionOrPanic call sites with statusOr returns boiling up to base server creation
4. as each plug-in gets a "throw free" creation mode, disallow new extensions of that type from throwing on creation

we'll probably have to keep the TRY/CATCH macros in Envoy code perpetually, but it'd be really fantastic to get at least core code building without it, and maybe some of the folks who are eager to do clean up work can work on moving older extensions to statusor mode.

[yanavlasov]

This will solve a lot of internal problems, trying to mix exception enabled Envoy code with exception disabled internal code. However it is going to a massive refactor.

[htuch]

I agree on the positives. The main challenge in core code is that it is a very common pattern to use exceptions during config ingestion for validation. There is no reason this code could not eventually move to an exception free model, but it would require a significant effort to switch to a pattern like statusOr across the board. Hopefully someone has the cycles for this work.

Will we also ask extensions to move away from exceptions once core is exception free? One concern is that currently exceptions are an "invisible" (i.e. not observable at compile time) part of the extension API interface.

[alyssawilk]

they're invisible by API but if you try to build fnoexceptions and you've got a lingering throw around the compiler will 100% catch it for you. As I've discovered a dozen times over the last month merging my no_exception branch =P

Should be pretty easy to switch the E-M build to no exceptions, then hopefully (but who knows) some day the core build. I don't think it's worth ever switching contrib, or asking folks downstream of Envoy to rework. it can be a permanent bazel option to compile out or in the TRY/CATCH macros

[adisuissa]

It is a non-trivial amount of work, but if there are benefits, then it may be a worthy cause.

I suggest adding files (maybe even directories) to this list whenever that file is clean.

[alyssawilk]

cc @paul-r-gall re 285574162 we can only dream....

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.