MATLAB has special functions for debugging m-file functions (but not scripts). You establish breakpoints within the m-file; when these are encountered control passes to the keyboard as with the keyboard command, giving a K.2ex>> prompt. You may then examine (or change) the variables with normal MATLAB commands.
Breakpoints are established with dbstop, in four ways. dbstop in m-file puts a breakpoint at the first executable line. dbstop at line in m-file puts one at the specified line number. dbstop if error causes a stop (in any m-file function) when a runtime error occurs; execution may not be continued after a runtime error. Finally, dbstop if naninf and dbstop if infnan cause stops (in any m-file function) when a value is noted to be Inf (infinite) or Not-a-Number (NaN). In all of these, the keywords at, in, and if are optional.
The command dbtype is similar to type, but it gives the line number of each line of the m-file, for setting breakpoints. It also takes as an optional third argument a vector of lines to display (instead of all of them).
A list of all breakpoints is available with dbstatus. Use dbclear to remove breakpoints; dbclear at line in m-file; dbclear all in m-file; dbclear in m-file (removes a breakpoint set at the first executable line); dbclear all; dbclear if error; and dbclear if naninf and dbclear if infnan (clear the breakpoints set by the corresponding forms of dbstop). As with dbstop, the keywords at, in, and if are optional.
Having finished exercising keyboard control at a breakpoint, use dbcont to resume execution after the breakpoint. Note that when the debugger prints out a line, that is the next line to be executed; it has not yet been executed.
Instead of letting execution continue to the next breakpoint, you can use dbstep number to execute the next number lines (one if number is omitted). This lets you examine the state everywhere without making every line a breakpoint. If the m-file being debugged is about to itself call an m-file function, dbstep in steps the debugger into the latter line by line instead of executing it as a single line.
To track which m-files called which, use dbstack. To change the scope of the local workspace -- that is, to have the variables you refer to at the K.2ex>> prompt be those of the m-file function or those of the function caller -- user dbdown and dbup respectively.
The command dbquit aborts execution of the m-file (returning nothing) and leaves debugging mode.