Maybe joe, nearly all this is doeable in RB currently except for one thing - the message text itself. This currently has to be "hard coded".
Consider a typical Assert call as it might be implemented using current RB: Assert(myVal > 0, "myVal > 0","Mymethodname","myclassname","line number" ) This provides all the text strings useful for tracing the bug. But what if the class or method names change ? We have to go through all the assert calls re-typing the new names. There is no "dynamic" generic way to derive that info. ( far as I know anyway ) . Consider also the cases in which blocks of code like this get copied and pasted to other places in the app. We then similarly have to go through all these assert calls re-modifying the strings. How much easier life would be if RB - wia the Assert call could provide this information. Such strings would then automatically contain the correct info. I know that one can surround Asserts with macros , but I contend that one thing proper use of Asserts can do is help reduce the number of code branching in apps that is purely down to asserts. I would rather have my ifs and thens reflect the ACTUAL app or business logic and hide away error traps wherever possible, for readability. This in a small way what the new aspect oriented programming buzz is all about - > >> >> But one would not be able to attempt to continue, unless every place you >> think an assert may be nonfatal, you write it as: >> >> try Assert foo catch AssertException end try >> >> ..which is a lot to write. > > I find in typical uses The try and catch for ASSERTS would be further up the > call chain. Maybe just once in the App itself. This is because I see > Asserts as being used to trap critical bugs where code execution shouldn't > be proceeding further. In any case the main issue as far as I see it is > those hard coded debug info strings. > > > > > > > On 22/11/06 17:27, "Joe Huber" <[EMAIL PROTECTED]> wrote: > >> At 10:57 AM +0000 11/22/06, Daniel Stenning wrote: >>> I would like it not only active in the IDE, but also in a special "Beta >>> test" release mode - whereby asserts gan generate error messages during beta >>> testing, but be ( optionally) ignored in the final release. >> >> I already do all of this in my own code, including posting the trace >> and stack data to my web server, for my beta and built apps. >> >> There's nothing standing in anyone's way from doing this TODAY. >> >> Regards, >> Joe Huber >> > > > > ------ End of Forwarded Message _______________________________________________ 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>
