> > No, these exceptions are raised in the compositing thread, right? Client
> code
> > has no opportunity to catch them.
>
> Any exception that reaches the top of the compositing threads (i.e. it is not
> handled by that thread), is caught, the server is torn down, and the exception
> is rethrown when run_mir() finishes.
>
> See the code in multi_threaded_compositor.cpp and the
> mir::terminate_with_current_exception() function for more.
Right.
What this proposal does is take code that leads to an orderly shutdown with an exception the client can (and is expected to) handle into an unconditional crash.
As I've stated before in this thread I don't think a library should behave this way.
> > No, these exceptions are raised in the compositing thread, right? Client compositor. cpp and the with_current_ exception( ) function for more.
> code
> > has no opportunity to catch them.
>
> Any exception that reaches the top of the compositing threads (i.e. it is not
> handled by that thread), is caught, the server is torn down, and the exception
> is rethrown when run_mir() finishes.
>
> See the code in multi_threaded_
> mir::terminate_
Right.
What this proposal does is take code that leads to an orderly shutdown with an exception the client can (and is expected to) handle into an unconditional crash.
As I've stated before in this thread I don't think a library should behave this way.