I think I should clarify some things up front. o First of all, to be able to add @throws to a function at any point, means that the compiler would internally replace the flag 'isnothrow' with a list of thrown exceptions. That is not much different from what there is now and would be part of the mangled name as well, if acceptable (length restraints), or - since you cannot overload by exceptions - part of an extension to the object file.
o nothrow would be equivalent to the empty list @throws() and usable interchangeably. o For protected and public methods of objects and interfaces that are not declared as nothrow, the thrown exceptions would inferred as @throws(Exception). This has to be done, since an override of these methods could introduce any exception type. o private methods and regular functions are properly inferred with the exceptions they actually throw. o At this point all the functions and methods carry their hidden @throws specification around, but it is neither visible in source code, nor is there any impact for developers. o Once someone adds an @throws to a function, the compiler compares it to its internal list and complains if it is missing an exception type. The explicit list can contain additional exceptions that aren't in the compiler inferred list and it can offer more general exceptions, like the base type Exception, as a catch-all. o What happens with object methods that don't declare anything? Since they are inferred as @throws(Exception), no narrowing is possible. On the other hand, I think this is the only natural way to handle it. Thoughts ? -- Marco