Question

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?

Answer 1

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).