Re: [Mingw-users] GCC 4.3.0 20080502 (alpha) Released - Please helpus test it!

[Aaron W. L. <aar...@aa...>]

Brian Dessent wrote:
> "Aaron W. LaFramboise" wrote:
> 
>> -Throwing non-SEH exceptions through arbitrary foreign frames isn't
>> really a valid thing to do anyway unless you're planning to terminate
>> immediately--and maybe not even then.  In the Win32 API case, it appears
>> to work most of the time, but I don't see any guarantee of this
>> documented anywhere.
> 
> Even if your code isn't designed to throw from the WndProc, it often can
> still happen if you have an unexpected exception occur as is common with
> C++ code that heavily uses the STL.

Can you clarify this case?  The STL generally does not throw exceptions 
unless the programmer asks it to.  The only unexpected exception 
situation I can think of is std::bad_alloc.


>  The fact that you can't install a
> catch-all handler at the toplevel that gracefully terminates the app
> with a friendly message means any little unexpected oopsie in the
> windowing code will kill the app cold with an ugly abort() and there's
> nothing you can do about it.

A user can override abort() if he likes.  Or, he can catch exceptions in 
the callback and propagate it properly.  In the WindowProc case, this 
means either rethrowing with SEH using RaiseException() or returning 
WM_QUIT--which as far as I know are the only documented valid means of 
leaving a WindowProc anyway.


 > Any codepath that goes through code that wasn't
> compiled with a DW2-enabled compiler is a potential source of failure --

This is also true of any other exception strategy, including both SEH 
and SJLJ.  It is not valid to throw through functions that don't know 
about exceptions unless they are specially written to accommodate this. 
  The primary problems are that it may leave dynamic data structures in 
an incoherent state or it may leak resources.


I understand the situation is not ideal, but due to the presence of the 
other mentioned mitigating factors, it seems this is the best way to 
proceed.

The users for whom this is problematic will simply have to wait a little 
longer to upgrade; but these are the users who will likely benefit the 
least from the newer versions, as they don't require the newer features 
anyway.


Here's some alternatives, and the reasons they were discarded.

-Delay release: No reason to delay release for everyone when only a 
minority user subset is affected.  We need to get this thing moving.

-Two separate compilers: Releasing two compilers with two incompatible 
ABIs will probably cause serious problems for our C++ users, hitting 
again once SJLJ is dropped, which would be fairly soon anyway.

-Only SJLJ: The poor performance of SJLJ makes Java impractically slow, 
and even in C++ causes problems for some code.  The ABI would be broken, 
again, during the upgrade, which, as I mentioned, will happen fairly 
soon.  There probably is only marginal value in releasing such a compiler.


What do you think?