Better Script Error Handling

Idea created by philmodjunk on Sep 17, 2016
    Active
    Score59

    Script Generated Errors in FileMaker are Inconsistently handled and do not offer developers effective means to handle each and every type of error even though competing products have offered very effective options for decades.

     

    I have previously suggested the following years ago, but am putting it here so that others can see, comment and vote as they see fit...

     

    a) All script errors returned to the script should be real errors from the context of how we as developers define an "error". As an example, Go To Record/Request/Page [next ; exit after last] should not generate an error code simply because the step is exiting a loop after reaching the last record in the found set. When searching through error logs or when setting the debugger to "pause on error", we have to wade past frequently logged errors or unnecessary pauses simply due to this so called error being returned. The FileMaker developers at HQ may have a good reason for considering this an "error" in terms of how the native code works, but in the context of how we develop a database, this is an error that makes no sense.

     

    b) Once a) is accomplished, all errors, as their default behavior, should pause the current script with an error message and provide users with an option to immediately halt the script. Currently, some errors, such as not finding any records in a find do this, Others produce an error message telling you bad things are going to happen (errors with Go To Related Records), but don't give you the option to halt the script and most do nothing at all except generate an error code that we won't see at the time unless we test for it immediately after the script step executes--creating a dangerous situation where a script may be run and produce incorrect results for an extended period of time before someone finally notices that the script is not producing correct results--this can literally produce a catastrophe for the people depending on that database.

     

    c) Once you have b) Set Error Capture[on] should suppress all such error dialogs. currently, if FileMaker attempts to create a file and is unable to do so (Save as PDF, Export Field Contents...), an error interrupts the script even if the developer tries to use Set Error Capture and uses Get ( LastError) to trap for the error code in order to put in place their own methods for handling the error.

     

    d) And once the above consistent error handling takes place, give us a script trigger like event that performs a script or portion of a script where we can use a get function to check the error code and then determine what happens next with an option to return control to just after where the error occurred in the originating script after the script handles the error.

     

    In Visual Basic, such an error handler has been available to developers for decades, but in FileMaker the only way that we could achieve the same type of developer created error handling would be to put a call to Get ( LastError ) after each and every step of our script--and the above inconsistencies make even that extreme form of coding unable to fully handle every such possible error.