Exception programming difficult

[Marco Leise]

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