DMD 1.027 and 2.011 releases

Russell Lewis webmaster at villagersonline.com
Wed Feb 27 20:27:24 PST 2008


I wonder if asserts() should be the exception to nothrow.  Like eao197, 
I normally run my programs with assert()s turned on.  But it would be a 
shame to lose nothrow because of that.

Are assert()s catchable?  Other than in some sort of weird systems 
programming context (where you are running one program inside another), 
why would you want to catch them?  (I'm sure somebody has a compelling 
example...but would that example be ruined by 
asserts-that-penetrate-nothrow.)

eao197 wrote:
> On Wed, 27 Feb 2008 16:56:34 +0300, Christopher Wright 
> <dhasenan at gmail.com> wrote:
> 
>> eao197 wrote:
>>> B.foo may looks like:
>>>  void foo() nothrow
>>>   in { assert( <some condition> ); }
>>>   out { assert( <some condition> ); }
>>>   body { <some code without exception> }
>>>  Body of B.foo() doesn't throw exception but assert in 
>>> pre/postcondition could do that. A call of B.foo could produce 
>>> exception but B.foo is declared as 'nothrow' :(
>>>
>>
>> I'm happy with that. Contracts aren't compiled in release mode, and 
>> they aren't part of the function; they're part of the tests. I'd hate 
>> to have to avoid one language feature for reliability in order to gain 
>> another one.
> 
> People are different. You want to compile your programs in release mode 
> to remove any run-time checks and contracts. I want to save them in my 
> programs to catch errors at the most earliest stage ('fail fast' 
> principle is very important in server-side systems). But a programing 
> language must provide logical and consistent rules for each of us.
> 
> --Regards,
> Yauheni Akhotnikau


More information about the Digitalmars-d-announce mailing list