Error management in OOP framework.

3 次查看（过去 30 天）
Cedric
Cedric 2017-12-1
编辑： Cedric 2017-12-3
Dear all,
1. I cannot use a global/outer try/catch statement, because the MException caught doesn't contain any reference/handle to the object that threw it. Concretely, if the main script is:
try
model = Model() ;
project = model.addProject( 'Test' ) ;
project.addScenario( NaN ) ;
catch ME
...
end
with
classdef Project < handle
methods
function addScenario( obj, name )
assert( ischar( name ), ... ) ;
...
there is no way to get a handle on project from ME, which stores only text (msgID, message), a stack (struct array of names and line numbers), and causes (cell array of other MException objects).
2. If I extend a little this mechanism with:
classdef Core < handle
methods
function assert( obj, test, varargin )
...
...
classdef Project < Core
methods
function addScenario( obj, name )
obj.assert( ischar( name ), ... ) ;
...
I could update the MException object in Core.assert (adding clauses), but again, there is no way to add a Project handle to a MException object, so there is no point in having the outer try/catch statement.
3. Accounting for this, I can extend a bit the mechanism and implement something along the following line:
classdef Core < handle
methods
function assert( obj, test, varargin )
if ~test
obj.errorManager( varargin ) ;
...
classdef Project < Core
methods
function addScenario( obj, name )
obj.assert( ischar( name ), ... ) ;
end
function errorManager( obj, varargin )
...
end
...
which is somehow satisfactory, because I can add an errorManager method to each sub-class of Core, as a separate file in each class folder, and implement as much error management/analysis/reporting as I want without "loading" the rest of the code in the class definition.
Yet, this is not completely satisfactory. I can easily truncate the (DB) stack from the report that I generate, i.e. the first two entries ( Project.errorManager and Core.assert) that should not be displayed, to avoid confusing users who should see Project.addScenario at the top as the source of the error.
But when I throw an exception ultimately from the error manager or elsewhere, it becomes difficult to prevent MATLAB from displaying these first entries. I looked for a way to pass or define a start stack depth for MATLAB to truncate the stack and I didn't find any. The stack property of MException objects is read-only so I am unable to (re)define it.
There are still a few messy alternatives, e.g. throw an exception, post-process the report (easily done using REGEXP and the output of getReport(ME)), print it to stderr, and generate an "empty enough" error, but these tricks seem to be ugly.
Hence my questions:
  • Did I miss a fundamental mechanism for managing these situations properly?
  • Do you have any cleaner alternative approach? (Keeping in mind that adding clauses to a MException object is not flexible enough).
Thank you,
Cedric

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

采纳的回答

Philip Borghesani
Philip Borghesani 2017-12-1
编辑：Philip Borghesani 2017-12-1
I am not sure if this code helps you or not but have you tried subclassing MException to add an object?
Things to look for in code:
  • Use of ThrowAsCaller to hide helper functions.
  • This code assumes object has name better to use evalc and disp of object in portable code.
  • Any number of types of exception are possible.
  • From the command line MException.last can be used to retrieve the exception object.
classdef ObjException < MException
methods
function obj=ObjException(src,varargin)
obj=obj@MException(varargin{:});
obj.sourceObj=src;
end
function rep=getReport(obj,varargin)
rep=sprintf('Object Error on object %s\n%s', obj.sourceObj.name, getReport@MException(obj,varargin{:}));
end
end
properties
sourceObj
end
end
classdef testobj
methods
function meth(obj,arg)
assert(obj,arg);
end
function assert(obj,cond,varargin)
if ~cond
if nargin>2
ex=ObjException(obj,varargin{:});
else
ex=ObjException(obj,'testobj:AssertFailed','assertion failed');
end
throwAsCaller(ex);
end
end
function error(obj,varargin)
ex=ObjException(obj,varargin{:});
throwAsCaller(ex);
end
end
properties
name
end
end
>> to=testobj
>> to.name='foo'
>> to.meth(true)
>> to.meth(false)
Object Error on object foo
Error using testobj/meth (line 4)
assertion failed
  2 个评论
Cedric
Cedric 2017-12-2
Hello Philip and thank you very much for your answer!
I've been testing your approach for a few hours and (after some fight because a base class method can only be called from the same method in a subclass), I think that I could adapt it to my case. I will go on tomorrow and update the thread accordingly.
Thanks again!
Cedric
Cedric 2017-12-3
编辑：Cedric 2017-12-3
I finished migrating to an approach based on your answer and it works well; thank you! In short,
  • ErrorManager built in Core.assert/error calls obj.errorManager where obj in an instance of a subclass of Core. Method errorManager is defined for each subclass in its own M-File in each class folder, so it can be as long as needed without "loading" and messing up the rest of the code.
  • PException<MException built in Core.assert/error, stores handle on current object and redefines method getReport.
  • PException.throwAsCaller (inherited from MException) is called at the end of Core.assert/error. It calls the overloaded getReport, which produces an extended report.

请先登录，再进行评论。

更多回答（0 个）

类别

在 Help Center 和 File Exchange 中查找有关 Software Development Tools 的更多信息

标签

产品

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by