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.

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.

On Sun, 31 Oct 2010 02:51:53 -0400, Don <nospam@nospam.com> wrote:

> 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.

I think you meant to say runtime-generated errors?  If it's just a spec change, then why is the compiler failing to compile the code?

-Steve