We may as well call a spade a spade.įor my own part, I've been reluctant to use Matt's Error* functions because they usually strike me as being too "heavy" for what I usually find myself doing with error handling. But as far as I can discern, an error structure is just a dictionary that we can trust to have values for particular names, and the ErrorObject function is a shortcut for generating it. Ordinarily, I like orthogonal functionality. I'm not sure whether I like the independence from a solution's dictionary functions or not. I'm reluctant to call that structure an "object" for fear of confusing developers more familiar with some object oriented language than with FileMaker: the resulting object has no methods (i.e.
This looks like a variation on the idea behind Matt's Error* functions, which is to create a data structure to mimic the role of thrown exception objects in other programming languages.
FILEMAKER BASEELEMENTS GITHUB CODE
Using the Custom Functionsĭiagnostic information more detailed than the error code is of course a handy thing to have. Over time, it would be nice to see the community and plugin developers contribute error handling custom functions for various plugins and services. The intention of these functions are to translate the error information provided by the SOURCE into the standardized format implemented by these custom functions. The code repository contains some examples of this type of function. Examples of plugin error functions would be ErrorPlugInScriptMaster or ErrorPlugInTroiDialog. Where SOURCE is unique to the origination of the error and is the same as/similar to errorType. Since $error is the reserved variable name for storing error data, this function will almost always be uses like this: ErrorFound ( $error ) Error ( any parameters necessary theErrorInfo ) In other words, if any error occurred at all, return True (1), otherwise return False (0). Return errorCode contained in theErrorData as a Boolean. This function should be modified by each developer/solution to map your own error codes to error descriptions. This variable contains name/value pairs, encoded by the # ( name value ) function and accessible by the #Get and #Assign functions. Due to the amount of possible supporting information around any given error, all information relating to the error should be saved to the reserved variable $error.
One of the primary goals is to capture environment specific information at the time of the error. if writing a mFM Module, the error type could be the name of the module, like: "mFM: JSON"īecause any error may have many different causal facets, such as relevant associated environmental information at the time the error occurred, a predefined number of error attributes is unrealistic.if you are interacting with a SOAP web service, the error type could be the name of the web service.When saving error data in a custom function, use the reserved variable $functionError.Īny error source can have it's own error type associated with it here are some examples: Plug-in specific error, specify the name of the plugin such as "Plugin: ScriptMaster", "Plugin : BaseElements", "Plugin : TroiDialog", etc.Ĭustom function specific error. An example of this would be a Perform script step higher in a sequence of steps which is required in order for subsequent Perform script steps to function properly. The following items are the suggested classifications for error types.Īn error which the developer generates within the logic of your own solution. We refer to the origin of an error as an error type. However, there are many external technologies (such as plugins), as well as the logic used to create your FileMaker solution which can also generate errors. These FileMaker error codes could be handled with FileMaker's own Get ( LastError ) function. The most fundamental errors within FileMaker are obviously those generated by FileMaker itself. It doesn't stop with just FileMaker the application. There are many places where an error can occur within a FileMaker solution. Once the functions are complete, they will be moved to the main fmpstandards repository. The temporary GitHub repository contains the custom functions mentioned on this page, and a sample FileMaker 12 file. Your FileMaker solution can potentially experience far more errors than just those generated by FileMaker itself. This page outlines a method of error handling which extends far beyond using FileMaker's own built-in Get ( LastError ) function. This page describes the intended implementation of error management within a FileMaker solution.
0 kommentar(er)
