Having not read the entire thread, I risk reiterating an idea that may have
already been brought up, but I believe I've got a few thoughts that may be of
value... and if somebody's already mentioned them, I hope they take this as a
compliment and a vote in their favor.
> Otherwise as
> you said, it will become necessary to include a number of different
> std::... exceptions in the throw specifiers for completeness or to
> ignore the fact that they may occur. Which brings up the question is it
> allowable to let the program terminate if say a std::bad_alloc exception
> is thrown.
>
> I think the current manual audit process for using exceptions and
> knowing exactly what is going on is the biggest killer for using
> exceptions properly in C++. That was the initial purpose of creating
> this project.
I think it might be a good idea for the throw specifier to include all types
derived from the specified types as acceptable exceptions, especially so for
virtual methods. A implementation of a virtual method in a derived class may
decide that the defacto-standard exception (that the base stated it would
throw) does not contain enough information to fully describe the error. The
derived method could then be free to throw an exception of a type derived from
the exception class that the base stated it would throw without violating the
throw specifiers that it inherits. Any user of the hierarchy in this example
could still catch only the specified exception types and not be at risk of
letting one slip by. Additionally, programmers using stl templates and letting
their exceptions pass thru could merely claim to throw std::exception (being
the parent of all stl exceptions... i hope) and not be considered incomplete.
> Yes. I agree completely. My first version of EDoc++ did not include the
> concept of suppressions, and it just became infeasible to use. There was
> too much information and a lot of it just really was not important to
> the average developer.
>
> Practically every function that included a throw specifier would emit
> errors if it used anything from STL as for example std::bad_alloc would
> be thrown or something similar. By using an external suppressions file
> it is possible to indicate locations where exceptions will not logically
> propagate even though the compiler thinks that they will as well as
> saying that std::bad_alloc among others are "runtime" exceptions
> equivalent to Java and not necessary in the specs.
>
> Again there are issues involved with maintaining an external
> suppressions file as opposed to some form of markup within the source code.
>
> Suppressions can also be used to say i am only interested in information
> for a certain set of functions or to restrict the callgraph that may
> have been pessimistically expanded from virtual functions or function
> pointer calls, or to add function calls (which is currently necessary
> when using plugins) or really to modify the resulting data in any way
> imaginable. (The suppressions file is actually a python script that can
> manipulate the EDoc++ applications internal data structures)
Two ideas come to mind: 1. Offer a class attribute that indicates an exception
type that is exempt from throw specification checking (__volatile_exception).
This could be applied to exception class like std::bad_alloc or other
exceptions that just might fly from anywhere. 2. Offer a function attribute(s)
to play the role of suppression specifiers (__suppresses and/or __catches...
they do represent slightly different meanings). Both of these ideas introduce a
level of danger that should be respected by developers, but so do const_cast
and reinterpret_cast.
> code compiled with
> -fno-exceptions linked with code that allows exceptions, same with C++
> and C code intermixed, templates and vague linkage, differing throws()
> specifiers for a functions prototype in different translation units, and
> the list of complexities goes on...
Anybody who does that deserves what they get (anybody who hires them, however,
might not). Perhaps the resulting throw specification could be emitted as
discardable records of some sort, and the linker could then be enhanced to rub
the offending programmer's nose in it (well... at least the differing throws()
scenario). Intermixed C & C++ is just a requirement of real life, and I haven't
seen anything about function pointers yet... you just have to take the
programmer's word on that one, right?
I've recently been in a situation where I had to use reference-counted
exception classes that could potentially be delivered to multiple receiving
threads, and the IO completion thread that generated them had to bucket them
with their respective IO buffers, but never get one thrown to it. Having such a
feature would have saved me days of sifting thru the hulking beast of an IO
subsystem that this design was deployed into. In other words, I would really
like to have a feature like this available.
- Brian
____________________________________________________________________________________
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html
