I understand what you are looking for in an abstract way, but I am having some problems with understanding particulars.

If I am writing code, the bad code might be in *my* code, but might not manifest until a deep call, ie

sum(‘a’, 1) %let’s pretend this code caused an error in SUM

Would you want to stop? The ‘error’ is thrown by SUM which is not in your directory, so should it be skipped or not? I personally want it to stop and then just run up the stack until I get to *my* code.

Like I said, I think there is something to this suggestion, but I am not sure what would cause a DBSTOP and what would not.

-Doug

I generally have one set of files that I’m debugging, and desire the “dbstop if error” functionality for files in that set. Everything else I don’t want to hear about, just give me the error message and let’s move on.

In terms of the interface, one possibility would be to implement the following calling convention:
DBSTOP in MFILE if error
As well as the “caught error”, “warning” variants.

-Mory

That’s a nice suggestion. I often get frustrated when debugging GUIDE guis and ending up inside of guimainfcn. I can’t think of a direct way to handle this – there might be some games you could do with stopping based on certain error IDs, but I’m not sure how far this would get you.

- scott

Cheers,

Eric