When MATLAB throws an error, if you are in a function, you will end up at the base workspace and lose access to the variables as they were in the function when the error was thrown. This makes it difficult to understand why the error occurred.
With the debugger, MATLAB can stop when the error is thrown, so the variables are still in scope. This makes debugging much easier.
It would be great to stop the debugger from coughing somewhere inside the more “internal” functions.
Is there a way to specify not to barf in certain directories, or in the ones you’re developing in only?
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.
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.
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
Leave a Reply
About
Doug Hull is a proud MathWorker who is on a mission to help you with MATLAB.
It would be great to stop the debugger from coughing somewhere inside the more “internal” functions.
Is there a way to specify not to barf in certain directories, or in the ones you’re developing in only?
Cheers,
Eric
Eric -
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
Hear hear!
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
Mory,
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