On Nov 22, 2006, at 06:28 UTC, Rubber Chicken Software Co. wrote: > Right, sure, you can write your own assertions; like this: > > #if DebugBuild > Assert(x = y) > #endif
Leave out the #if and #endif, and it will be both better (assertions should be in the final product in almost all cases) and more readable. > But look how bulky that is. It makes code unreadable, really. Any > "nest" screws up your field of vision. Readable code is important. > Plus, I'm in no mood to type all that in sometimes. Right. So leave out the bulk of it and include just the correct part. :) > Now, it's funny that I see them somewhat dissing a standard concept. > Brendon's exactly right - at the very least, we should be seeing a > #assert(boolean) function that doesn't get compiled but is active in the IDE. You could write your Assert to do nothing in a release build, but it's not clear to me why you would want to. At the very least, it should log the error to a file that you can then ask your users for when things seem to go wrong. (And things WILL go wrong.) It's also not clear to me how RS could write this Assert method for you. I'm quite sure they don't know what I want it to do, since in different projects I may have it do different things. One client wants it to display a message box; another wants it to use System.DebugLog; a third wants the error written to their own log file. If they were to implement it, what makes you think they would choose whatever functionality you happen to prefer? Best, - Joe -- Joe Strout -- [EMAIL PROTECTED] Verified Express, LLC "Making the Internet a Better Place" http://www.verex.com/ _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
