Am Mon, 13 Aug 2012 19:32:38 +0400 schrieb Dmitry Olshansky <dmitry.o...@gmail.com>:
> I think the true cryptonite that melts "checked exceptions" to a pile of > green goo is templated code: > > So (*yawn*) tell what kind of exception specification the following > function should have: > > auto joiner(RoR, Separator)(RoR r, Separator sep); > > How would you guarantee upfront what kind of exceptions it can throw is > beyond me. It all depends on code that you can't reach or know by the > very definition of template. At first I thought the very definition of template doesn't do much in terms of nothrow inference, so what. But I made it to easy on myself, so I'll go into details a bit. When the template is instantiated and it has no @throws annotations, it would infer the thrown exceptions in the fashion nothrow is inferred. If you add nothrow/@throws to a surrounding function that uses this instantiation, then you get into the situation that you really don't know upfront what is thrown until you do a test compile. I could blame it on the compile time duck typing, that evades declared thrown exceptions. It seems that exceptions just don't work with templates [that call arbitrary functions passed to them through struct/class parameters]. In general it is not possible to reason about the thrown exceptions in templated code, unless everything is marked nothrow or the code is simple, like chains of filter, map, reduce, …. Currently you cannot use joiner in nothrow functions and I have no idea which exception you are supposed to catch. This is a whole different topic and for the sake of this proposal I'd like to go with not documenting these exceptions introduced from the outside, but making them aware to the programmer whenever he/she uses @throws on functions using such templates. -- Marco
