How to obtain an MException in a cleanup function

6 次查看（过去 30 天）

Matt 2020-10-26

1
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/626968-how-to-obtain-an-mexception-in-a-cleanup-function

编辑： Matt 2020-10-28

Hi all,

I've noticed that "lasterror" indicates that it will be obsolete soon, and MException.last indications that it can only be used from the command line. Without using a try/catch construct in the calling/parent function that is being cleaned up, is there any good way to check to see if the calling function being cleaned up generated an error?

14 个评论
显示 12更早的评论隐藏 12更早的评论

Steven Lord 2020-10-27

在 MATLAB Online 中打开

In the pattern you describe, a try / catch block would be my choice of approaches to use. You only want to log the error data if an error actually occurs and you only want to log the error if it comes from the scope of your function. As written your myNiceOnCleanup function will always get executed, error or no error. In addition there's a chance (albeit a slim one) it could catch an error from a timer object's TimerFcn, a Handle Graphics callback function, etc. [I'm not sure offhand how or if lasterror interacts with a parallel.ThreadPool but I wouldn't be surprised if "complicated" appears more than once in the answer.]

function myNiceFunction(usersBuggyFunctionHandle)
%Do Some setup
try
outputData = usersBuggyFunctionHandle();
%<--- User needs to be able to natively debug this with dbstop if error
catch errorData
myNiceOnCleanup(errorData)
end
end
function myNiceOnCleanup(errorData)
% Process the MException
logErrorData(errorData)
rethrow(errorData) % or throwAsCaller
end

As for debugging this, if an error occurs the user can set a breakpoint on the line inside the catch where myNiceOnCleanup is called. Or maybe this function accepts an optional input and you have a section in your code that calls keyboard if it is specified.

Steven Lord 2020-10-27

If you want to unconditionally stop in the catch block, add a call to keyboard.

Matt 2020-10-28

编辑：Matt 2020-10-28

Hi Steven, the two needed behaviors (in order of importance) are

1) To unconditionally stop where a crash occurs (or at least in the same workspace), when the crash occurs, the first time the crash occurs. This is doable with dbstop if error if there isn't a try/catch statement. Try catch doesn't support it.*

2) Log exceptions when they occur. Currently the lasterror function allows a flawed but useable implementation of this.

*Try catch doesn't support this because keyboards or rethrows will cause the debugger to stop in the workspace where the try/catch block is, not where the exception originally occured in the users code. dbstop if caught error does nominally supports this, but as I mentioned above its really not useable in its current state because it catches exceptions in the try/catch blocks in built in code.

请先登录，再进行评论。

请先登录，再回答此问题。