try {
int *blah = new int;
delete blah;
delete blah; // Uh Oh!
}
catch ( ... )
{
// Do something
}
Exception Question
Author
Say I am writing an IDE (complete w/ compiler and debugger). While debugging, if the programmer's code does something that causes a run-time error, I do not want the entire IDE to close. In my application, my debugger is running in a separate thread. Essentially what I want to do is: whenever a run-time error occurs, get that message and stop debugging (stop the thread).
My first idea was try/catch blocks, but the following doesn't work. I apparently need to 'throw' in order to catch, but my debugger is not looking for errors - I only want to deal with the errors when the occur; therefore I never do any throwing.
Which operating system?
If it's Windows, this article might help point the way: The Win32 Debugging Application Programming Interface. The source code that goes with that article might be here, but it might not be.
Try-catch blocks in the debugger should only catch exceptions thrown by the debugger itself, not the debuggee.
If it's Windows, this article might help point the way: The Win32 Debugging Application Programming Interface. The source code that goes with that article might be here, but it might not be.
Try-catch blocks in the debugger should only catch exceptions thrown by the debugger itself, not the debuggee.
Author
Yikes! I was hoping it would be a bit simpler than that article. Thanks for the link, though.
I am currently developing for Windows. However, the application is completely cross-platform. While it's not necessary to keep it that way, it is a nice perk. That article is completely Win32 dependent. Even if I were limiting myself only to Windows, I want to avoid those low level Win32 API calls as the article presents.
Seems like there should be an easier way to do this... any other ideas?
I am currently developing for Windows. However, the application is completely cross-platform. While it's not necessary to keep it that way, it is a nice perk. That article is completely Win32 dependent. Even if I were limiting myself only to Windows, I want to avoid those low level Win32 API calls as the article presents.
Seems like there should be an easier way to do this... any other ideas?
Author
Doing some thinking on the issue.... The language being implemented is fairly primitive. I could probably come up with a list of 20 or less items that could cause a run-time error. I would wrap the debugger in a try/catch block. For each of the possible run-time error issues, I would just do conditional checks in the given functions. So for a division by 0 run-time error, in the function that executes a division instruction, I have the condition:
if ( divisor == 0 )
throw;
I could devise my own exceptions, which will be caught. Upon catching, I spit out an error message and shut down the debugging thread.
This seems like it should work. This is assuming all run-time errors can be accounted for. Hmmmm...
if ( divisor == 0 )
throw;
I could devise my own exceptions, which will be caught. Upon catching, I spit out an error message and shut down the debugging thread.
This seems like it should work. This is assuming all run-time errors can be accounted for. Hmmmm...
I see. I thought you were talking about writing a process debugger. I'm not sure how to go about writing a debugger for a scripting language. It seems to me that it would be important to isolate the thread executing the code from all other threads in the process. That way the other threads could manipulate the code execution thread - pausing and restarting it as needed - while allowing the debugger to continue running.
As for try/catch/throw and the approach you've sketched out - it might work. It seems however that you might get more bang from a syntax checker or rather a program checker like lint [1]. That is, using static analysis of the code - which is kind of like what you've described in your last post.
The trouble with run-time error checking in this context is that exceptions ultimately eminate from the cpu itself - and you don't want to go there if you're aiming for cross-platform compatibility.
You might also consider asking about this in the scripting forum. I can move this thread there for you if you'd like.
As for try/catch/throw and the approach you've sketched out - it might work. It seems however that you might get more bang from a syntax checker or rather a program checker like lint [1]. That is, using static analysis of the code - which is kind of like what you've described in your last post.
The trouble with run-time error checking in this context is that exceptions ultimately eminate from the cpu itself - and you don't want to go there if you're aiming for cross-platform compatibility.
You might also consider asking about this in the scripting forum. I can move this thread there for you if you'd like.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
