Re: [Edoc-main] Skip throw() function pointers?

[Brendon C. <bc...@av...>]

Niko Ritari wrote:
> On Tue, 2007-12-11 at 14:35 +1100, Brendon Costa wrote: 
> Ignore this part if you want to. I'm failing to understand why EDoc++
> works like it does with the simplest of test programs:
> 
> void f() {
>     try {
>         throw;
>     } catch (int) { }
> }
> 
> int main() {
>     try {
>         throw 0;
>     } catch (int) {
>         f();
>     }
> } 
> 
> Here, EDoc++ issues a WUNUSED_CATCH about the catch block in f. With the
> quoted explanation (about "MAYBE catching"), I don't see why. It also
> tells me int may propagate out of main, but that's to be expected when
> exceptions out of f is approximated to "...", without excluding int.
> 

The current method is not accurate. It is a best effort approach that
will produce more warnings/errors than may be necessary. It should
however not silently skip over problems.

That above is another item to add to the tests and see exactly what is
happening. Again i dont have the time right now to look at it in more
detail, but i agree that it should not be emitting the WUNUSED_CATCH
as it should process the catch block with a partial match to type
"...". It could be that since EDoc++ can not tell if the catch block
will be used, it will emit the warning anyway.


>> That iterative approach might just work quite well! Start with a
>> complete union and iterate until nothing changes or some maximum
>> value... It certainly is worth looking into and I think it will be
>> much faster than the current method.
> 
> I would still very much prefer it without the union, getting the exact
> result with the drawback of having to execute the algorithm to
> completion in order to avoid false negatives. Ideally, implement both,
> so that the user can choose the union method if the unoptimized exact
> one is too slow. It wouldn't probably even take many lines of extra code
> on top of a union + iteration implementation, just start with empty sets
> instead of the union.
> 
> It's too easy to think of programs where two functions get a long list
> of bogus exceptions from the union, and keep passing them to each other.
> 

Again. I am keen to solve this problem as best I can. You have given
me some options to follow. Its just that the period around Christmas
is bad for finding spare time.


> This sounds good enough. Either more or less work for the user depending
> on the program, clearer code with typedefs, and no need to know the
> possible exceptions.
> 
> Unfortunately, this leaves the user the responsibility of avoiding an
> equivalent of "t2 = Type1DoStuff1;", whereas the compiler should
> automatically check the exception specifications.
> 

I agree here, but there is not much i can think of to solve the
problem otherwise. Leaving too much responsibility for the user
introduces more places for errors to occur, but it is just a difficult
problem trying to automate this.



> However, the exception specification approach just lost a lot of its
> appeal: It seems that currently GCC (at least a not-so-current 4.1.1)
> actually does not check exception specs in any way in function pointer
> assignment. Funny enough, it does check them in overriding virtual
> functions.
> 

Yep. The whole exception spec thing in C++ has been poorly thought
about and poorly implemented in my view. I can understand some peoples
reasoning for the way it is, but there would not be a need for EDoc++
if the C++ language had better support for exceptions.


Thanks,
Brendon.