"logo.gif"  
Main
Read Online
Download PDF
Additional resources
Revision history
Known typos/bugs
Report a bug
License terms
About the author
"node486_1.gif" "node486_2.gif" "node486_3.gif"

5.3.2.4.4     A digression : stricter error - checking

If this convention is unsatisfactory, and one needs a stricter condition which would issue an error message in such an event, then it is best to relegate this to patterns by modifying them appropriately :

"node486_4.gif"

Note that  the other possibility would be to again use the If statement inside the MapThread, which should then take the proper action when an erroneous input is encountered.  But this solution is typically worse for several reasons : a) Some part of the evaluation would typically have happened. This may be undesirable both because time has been wasted and because side effects may have been introduced. b) MapThread, like many other functional constructs, can not be normally "stopped" - thus, one will have to throw an exception.  c) A minor one: presence of If slows the function down a bit.  

This sort of solution can be used when the error condition can not be determined solely by input data, but instead depends on the results already obtained in the course of execution of a given function. However, such behavior is not typical for programs designed within the functional programming paradigm (at least, in Mathematica), mainly because it is usually caused by side-effects such as run-time assignments or in-place data modifications.

Returning to the code above, I used the opportunity to illustrate another possible way to attach a condition to the function definition: instead of attaching it right after the "declaration" part, we can attach it at the end, after the right hand side of the definition. Also, notice once again that we have exploited the way in which Mathematica applies definitions (rules, associated with a function) - more specific before more general, to implement error-checking.

Be sure to understand the use of Map , Apply and Sequence in the first definition above code. Check :

"node486_5.gif"

"node486_6.gif"

"node486_7.gif"

"node486_8.gif"

"node486_9.gif"

"node486_10.gif"

Of course, instead of printing error messages, any other desired action can be taken. In fact, returning error messages in the above fashion (or, worse yet, printing them with the Print command) may be ok for quick-and-dirty functions you write for yourself (say, in the exploratory stage), but not when you place your functions into packages. There exists a much better mechanism of Messages one should use in package writing. This topic is generally beyond the scope of our present discussion, so consult the books of Maeder and Wagner, as well as Mathematica Help and Mathematica Book, for details.

The additional error - checking overhead due to the pattern - matching is usually not too considerable if the patterns are mostly syntactic in nature (such as {__Integer}), or when they do some simple things like checking the list sizes. Of course, error - checking has to be done in any case if one wants to have a robust functionality. Sometimes, however, the user of the function knows for sure that the supplied data are correct (for instance, they come as a result of another function), in which case error - checking may be redundant. One possibility is to provide an option (say, with the name ArgTest) which will tell whether or not to perform the error checking :

"node486_11.gif"

This is however not completely safe in general, since this assumes a high level of competence (with this particular functionality) from the user. This sort of solution can be used in functions that are used only by a developer to build something on top of them.   

A safer alternative would be to place several related functions in a package, so that the auxiliary ones may exchange information without redundant type checks, and the interface ones which are exported to the end user do the type checks, but only once.

"node486_12.gif" "node486_13.gif" "node486_14.gif"

Created by Wolfram Mathematica 6.0  (05 February 2009) Valid XHTML 1.1!