Walter Bright wrote:

> It would work just like "nothrow" does for C++.

BTW, wasn't there one of your arguments to have no negation in keywords? Which would make "exfree" a better choice?

-manfred

Manfred Nowak wrote:
> Walter Bright wrote:
> 
>> It would work just like "nothrow" does for C++.
> 
> BTW, wasn't there one of your arguments to have no negation in keywords?

Yes. But everyone knows what "nothrow" means.

> Which would make "exfree" a better choice?

On Sun, 24 Feb 2008 11:53:00 -0800, Walter Bright wrote:

> Manfred Nowak wrote:
>> Walter Bright wrote:
>> 
>>> It would work just like "nothrow" does for C++.
>> 
>> BTW, wasn't there one of your arguments to have no negation in keywords?
> 
> Yes. But everyone knows what "nothrow" means.

ROTFLMAO

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

> It would work just like "nothrow" does for C++.

Just checking - I hope this means that if a nothrow function actually DID try to throw an exception (by calling something that throws), compiler- generated code would trap it and terminate the program with an error message?

Graham St Jack wrote:
>> It would work just like "nothrow" does for C++.
> 
> Just checking - I hope this means that if a nothrow function actually DID try to throw an exception (by calling something that throws), compiler-
> generated code would trap it and terminate the program with an error message?

No, but it will try to detect errors at compile time.

Walter Bright escribió:
> Graham St Jack wrote:
>>> It would work just like "nothrow" does for C++.
>>
>> Just checking - I hope this means that if a nothrow function actually DID try to throw an exception (by calling something that throws), compiler-
>> generated code would trap it and terminate the program with an error message?
> 
> No, but it will try to detect errors at compile time.

Does this mean this will not compile:

int foo(int[] someArray, int someIndex) nothrow {
	return someArray[someIndex];
}

but this will:

int foo(int[] someArray, int someIndex) nothrow {
	if (someIndex < someArray.length) {
		return someArray[someIndex];
	} else {
		return -1;
	}
}

Ary Borenszweig wrote:
> Does this mean this will not compile:
> 
> int foo(int[] someArray, int someIndex) nothrow {
>     return someArray[someIndex];
> }
> 
> but this will:
> 
> int foo(int[] someArray, int someIndex) nothrow {
>     if (someIndex < someArray.length) {
>         return someArray[someIndex];
>     } else {
>         return -1;
>     }
> }

I don't know yet. But the idea is to do static checking of what can throw.

On Mon, 25 Feb 2008 01:44:15 -0800, Walter Bright wrote:

> Ary Borenszweig wrote:
>> Does this mean this will not compile:
>> 
>> int foo(int[] someArray, int someIndex) nothrow {
>>     return someArray[someIndex];
>> }
>> 
>> but this will:
>> 
>> int foo(int[] someArray, int someIndex) nothrow {
>>     if (someIndex < someArray.length) {
>>         return someArray[someIndex];
>>     } else {
>>         return -1;
>>     }
>> }
> 
> I don't know yet. But the idea is to do static checking of what can throw.

It will be a good trick if you can pull it off. I don't see how it can be done without examining the source code of all the called functions, leaving us back where we started with throw specs.

The C++ approach of a runtime check isn't perfect, but at least it can be done, and provides a more definite form of documentation than comments.

If the static checks aren't done well enough and runtime checks aren't done at all, I would prefer to rely on comments.

On Mon, 25 Feb 2008 12:44:15 +0300, Walter Bright <newshound1@digitalmars.com> wrote:

> Ary Borenszweig wrote:
>> Does this mean this will not compile:
>>  int foo(int[] someArray, int someIndex) nothrow {
>>     return someArray[someIndex];
>> }
>>  but this will:
>>  int foo(int[] someArray, int someIndex) nothrow {
>>     if (someIndex < someArray.length) {
>>         return someArray[someIndex];
>>     } else {
>>         return -1;
>>     }
>> }
>
> I don't know yet. But the idea is to do static checking of what can throw.

Just my $0.02 about nothrow and DesignByContract: I think that nothrow are incompatible with DbC. A function/method could have contracts or nothrow but not both of them. It is especially actual for virtual (non-final) methods. Suppose that some class has:

class A {
  public void cleanup() nothrow { ... };
}

so it could be safely used in 'finally' statement:

A someResource = acquireResource();
try { ... /* some processing */ ... }
finally {
  someResource.cleanup; /* looks like exception-safe action */
}

But if there is a derived class B, which overrides cleanup() with postcondition:

class B : A {
  public void cleanup() nothrow
    out { ... some checking ... }
    body { ... some actions ... }
}

and acquireResource() would return B instead of A, then the code above won't be exception-safe. Moreover the behaviour of 'someResource.cleanup' would depend on compiler switches.

-- 
Regards,
Yauheni Akhotnikau

Walter Bright wrote:
> Graham St Jack wrote:
>>> It would work just like "nothrow" does for C++.
>>
>> Just checking - I hope this means that if a nothrow function actually DID try to throw an exception (by calling something that throws), compiler-
>> generated code would trap it and terminate the program with an error message?
> 
> No, but it will try to detect errors at compile time.

And nothrow will be a valid part of a delegate signature, correct? So I can use nothrow with delegates.

Nothrow is especially tricky because it doesn't require a function call to get an exception. But those cases are relatively rare.