exception types & objects

[Don]

Stewart Gordon wrote:
> On 19/10/2010 23:23, Jonathan M Davis wrote:
> <snip>
>> Perhaps, but there is no real benefit in throwing anything other than
>> an Exception (or Error upon occasion) and if we allow you to throw
>> anything than catch(Exception e) won't catch them all. It also would
>> pretty much violate nothrow since nothrow guarantees that no
>> Exceptions are thrown from that function, and if you can throw any
>> old object anyway...
> <snip>
> 
> Indeed, "Nothrow functions do not throw any exceptions derived from 
> class Exception" - seems odd to me.
> 
> I think I've had two uses in my time for throwing something that isn't 
> an Exception:
> - in a previous version of SDWF, to handle an awkward corner case in the 
> Windows dialog API, though I later found a better way of dealing with it
> - in the runtime for an Unlambda to D compiler, to serve as the 
> continuation object, though that could just as well be changed
> 
> I hadn't realised until now that D2 had changed to have a Throwable 
> class and Error and Exception classes derived therefrom.  It seems the 
> intention was to prevent a nothrow function throwing anything other than 
> an Error, but it wasn't quite said right.  So any solution should 
> probably prevent circumvention by creating a whole new subclass of 
> Throwable.  (By a quick look through the Java API docs, checked 
> exception classes are defined as Throwable minus the RuntimeException 
> and Error subclasses.)
> 
> Stewart.

nothrow actually prevents you from throwing anything. A nothrow function 
may still perform operations which may throw a compiler-generated Error.
(eg, AssertError, OutOfMemoryError).
It's only a spec change which is required.