On 6/4/07 16:52, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> On Apr 06, 2007, at 15:40 UTC, Daniel Stenning wrote: > >> This is because , while I find breaks so useful for >> trapping errors ( both just in terms of typing and due to the >> debugging limitations of exception ) when it comes to final builds I >> need to go through the code replacing all breaks with a >> raiseException. >> >> It would be nice if we could just specify a default exception to >> replace all breaks. > > Hmm, that's interesting. I wouldn't use that; I use "break" only in > cases where I want to stop in the debugger but not stop (or stop in > some manner I control) in a built app. For example, my unit-testing > module always does a message box followed by a break. In the IDE, this > takes me right to where I can inspect the problem, and in a built app, > it displays just the message and then goes on. Raising an exception > would not be helpful. Yes , thinking about it, that scenario just happens to the current app I was working on. > > But if you typically use break where you'd what to also raise an > exception, then why not make a global method that does both (or, if you > prefer, raises the exception only when DebugBuild is false)? Then you > don't have to replace anything, and don't need any new features either. I have tried this in the past, but didn't like the fact that the debugger then stops inside the global function instead of on the source line in question. A trivial thing I know, but I just find that being able to STOP on the errant line itself is more readable ( and I'm too lazy to mouse up the call stack ;) ) > >> I think to go along with this there is a need for more introspection >> features within RB so we can generate a very helpful "generic" error >> logging system, one which could - for example - OPTIONALLY - allow us >> to include not only the class/method causing the error but also the >> source line number. > > You can do that today by raising an exception, immediately catchng it, > and then examining its Stack array. Sure, I do this at the moment ( its a bit messy to do though, it would help if RS presented the stack data in a more readable form ). The only thing missing that would be nice is the line number. > >> In addition a "class instance ID" would be useful >> - ie to optionally be able to make the app generate an unique ID for >> each instance of a class, that can be reported in error messages. > > It already does; assign the object to a Variant and examine > Variant.Hash. This is the same value you see in the debugger if you > have "Show Object IDs" turned on. Wow - didn't know that - I'll have to try that out some time. The only thing is that the object instance might or might not still exist or be accessible for inspection, depending on where the exception gets caught. How would one get the errant class instance if - for example the exception got caught much further up level wise - for example in the App.UnhandledException event ? I think it would be more useful for the stack array to be able to also contain the object instance ID info. > > 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: > <http://support.realsoftware.com/listarchives/lists.html> > Regards, Dan _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
