Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Best practices for MATLAB message IDs?

When creation a MATLAB exception (MException object) or printing a warning or error message, MATLAB lets you supply a message ID that defines the except you're throwing.

The message ID is in the format:

component:mnemonic

For example, MATLAB's own undefined variable message ID is:

MATLAB:dispatcher:nameConflict

So when you use exceptions in your own code, what do you use for a message ID? Do you reuse MATLAB's default ones? Make up your own? What do you use for the component and mnemonic strings?

like image 573
jjkparker Avatar asked Jun 24 '10 14:06

jjkparker


People also ask

How to check warnings in MATLAB?

Select MATLAB > Code Analyzer, and then select the Enable integrated warning and error messages check box. Set the Underlining option to Underline warnings and errors . When continuous code checking is enabled, MATLAB displays warning and error messages about your code in the Editor and Live Editor.

What is Matlab Coder?

MATLAB Coder™ generates C and C++ code from MATLAB® code for a variety of hardware platforms, from desktop systems to embedded hardware. It supports most of the MATLAB language and a wide range of toolboxes. You can integrate the generated code into your projects as source code, static libraries, or dynamic libraries.


2 Answers

I generally follow this pattern for error (or warning) message identifiers, where things in parentheses may or may not be present:

(className):(parentFunction):functionWhereErrorOccurs:descriptiveMnemonic

The components are:

  • className: The name of the class, if the function where the error occurs is a method/constructor.

  • parentFunction: If the function where the error occurs is a subfunction in an m-file or a nested function, this would be the primary m-file function or the parent of the nested function, respectively. You could therefore have multiple parentFunction components.

  • functionWhereErrorOccurs: The name of this component is pretty self-explanatory. ;)

  • descriptiveMnemonic: I stress descriptive. For example inputError doesn't really tell me anything, but notEnoughInputs makes it clear that I didn't pass enough arguments. I always use lower camel case for the mnemonic, where the first letter of a word is capitalized except for the very first word.

The className and parentFunction components could be considered somewhat redundant, since the stack property of the MException class already identifies a complete path to the parent m-file and the line number of the error. However, one of the purposes of a message identifier is that it allows you to uniquely identify an error for purposes other than just hunting down the source of the error.

Let's say you have a function myFcn and a class myClass that overloads myFcn. If you make an error message identifier for the first one be myFcn:maxIterationsReached and an error message identifier for the second one be myClass:myFcn:maxIterationsReached, this would allow you to, for example, set a breakpoint with DBSTOP that halts execution only when this error is produced by myClass\myFcn and not myFcn. Likewise, unique warning message identifiers are useful in that you can specifically choose to ignore warnings from specific functions while letting others be displayed.

Additionally, you could also include components in the identifier indicating that the function where the error occurs is located in a package folder or a private folder (but this might make for a rather long identifier).

like image 137
gnovice Avatar answered Sep 28 '22 04:09

gnovice


In my work I use YMA:(mainFunctionName):(descriptiveMnemonic), where YMA are simply my initials. For example, all the warnings and errors invoked in my UIInspect utility have IDs similar to YMA:uiinspect:XXX.

like image 22
Yair Altman Avatar answered Sep 28 '22 04:09

Yair Altman