How to tell what subfunction ran last in a GUI? For debugging.
1 visualización (últimos 30 días)
Mostrar comentarios más antiguos
KAE
el 27 de Jun. de 2017
Comentada: KAE
el 5 de Jul. de 2017
I am testing a complex GUI written by someone else. If I push certain buttons in sequence a bug appears: instead of plotting a recently-loaded image, an old image is plotted. It's hard to tell what part of the program causes the bug: each button calls several functions, and there are many imshow calls. To pinpoint which imshow command retrieves the outdated image, is there a way to tell what function or line of code last ran, perhaps from the command line?
[Since I don't know where in the code the problem occurs, breakpoints are cumbersome because I'd have to put them into all the functions, plus I find it hard to 'step out' of debugging which I believe is a known issue with GUIs in R2015b.]
7 comentarios
Image Analyst
el 1 de Jul. de 2017
I don't know why it would be harder to debug if all your functions are in the same file. Actually I find it easier. If you had 30 functions that you were editing, then you'd have 30 editor windows open instead of one. Since they won't all show up, if you want to go to one, you have to use that little down arrow on the tab strip. So if you want to go to a function you can either type control-D if your cursor is in the function to go to its definition, which would either be in the same file or in a different file. OR you can search for it - in the same file you'd use control-f but if you had separate files for each function you'd need to use control-shift-f. Personally if I am not planning on using those functions in any other file, I put them inside the only file where they will ever be used. If a function will be used by many other programs, like a useful utility function, then I have it in its own file in my "Utilities" folder.
Respuesta aceptada
Image Analyst
el 28 de Jun. de 2017
Editada: Image Analyst
el 28 de Jun. de 2017
Yes, you can tell from the call stack. One way to do it is to simply put a fprintf() as the first line of every function saying what is executing. But if you want stuff shown/printed only when there is an error, you can look at the call stack. Wrap the contents of all your functions in a try/catch block:
% Sample usage
try
% Some code that might throw an error......
catch ME
callStackString = GetCallStack(ME);
errorMessage = sprintf('Error in program %s.\nTraceback (most recent at top):\n%s\nError Message:\n%s', ...
mfilename, callStackString, ME.message);
WarnUser(errorMessage);
end
The function GetCallStack() is attached below.
Más respuestas (0)
Ver también
Categorías
Más información sobre Environment and Settings en Help Center y File Exchange.
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!