Hi,

For some reason, one can't throw exceptions within In/Out blocks. This seems rather arbitrary; moreover, it's pointless because you can get around it with a dummy function.

So, is this "by-design," or just an oversight?

Either way, it would be nice to eliminate this inconvenient restriction.

Thanks,
--AJG.

On Sun, 21 Aug 2005 04:59:25 +0000 (UTC), AJG wrote:

> Hi,
> 
> For some reason, one can't throw exceptions within In/Out blocks. This seems rather arbitrary; moreover, it's pointless because you can get around it with a dummy function.
> 
> So, is this "by-design," or just an oversight?
> 
> Either way, it would be nice to eliminate this inconvenient restriction.

At first, I thought this might be because contract failures are not meant to be recoverable, but from testing it seems you can catch an assert error coming from an out{} block. So I don't understand this restriction either. Is it documented?

-- 
Derek Parnell
Melbourne, Australia
21/08/2005 3:42:02 PM

>> For some reason, one can't throw exceptions within In/Out blocks. This seems rather arbitrary; moreover, it's pointless because you can get around it with a dummy function.
>> 
>> So, is this "by-design," or just an oversight?
>> 
>> Either way, it would be nice to eliminate this inconvenient restriction.
>
>At first, I thought this might be because contract failures are not meant to be recoverable, but from testing it seems you can catch an assert error coming from an out{} block. So I don't understand this restriction either. Is it documented?

I haven't seen it anywhere.
I say leave the docs alone, and just get rid of it ;).
--AJG.

AJG schrieb:

>>>For some reason, one can't throw exceptions within In/Out blocks. This seems rather arbitrary; moreover, it's pointless because you can get around it with a dummy function.
>>>
>>>So, is this "by-design," or just an oversight?
>>>
>>>Either way, it would be nice to eliminate this inconvenient restriction.
>>
>>At first, I thought this might be because contract failures are not meant to be recoverable, but from testing it seems you can catch an assert error coming from an out{} block. So I don't understand this restriction either. Is it documented?
> 
> 
> I haven't seen it anywhere.
> I say leave the docs alone, and just get rid of it ;).

There are two interesting question tough.

http://www.digitalmars.com/d/dbc.html
# By definition, if a pre contract fails, then the body received bad
# parameters. An InException is thrown. If a post contract fails, then
# there is a bug in the body. An OutException is thrown.

# Any other D statement or expression is allowed in the bodies, but it
# is important to ensure that the code has no side effects, and that the
# release version of the code will not depend on any effects of the
# code.

1)
Has "throw" side effects?

2)
If "throw" has now side effects, what is the exception tree of the
following code?

a) Exception -> SomeException
b) Exception -> {auto insert: InException} -> Exception

****
class SomeException : Exception{
}

void sample()
in{
	throw new SomeException;
}body{
}

Thomas