This would be a good question for the "Scripting and Calculations" forum. I'm sure you'd get some good responses. It doesn't seem like something we'd want to take up the PM's time with.
It offers you a way to deal with user entry mistakes (or script mistakes) and either solve the issue in the following script steps or start a dialog with some human readable message and instructions what to do next. Then depending on the users feedback, deal with it. The optios are plenty; if Error <>0, you may choose to exit a script, revert a record, start a dialog to get users input, correct a users entry etc etc
In most solutions, almost every script starts with:
Set ErrorCapture ON
Set Allow User Abort OFF
This gives you as developer a great responsibility to trap for any possible error that a script could encounter and would cause it to hang or would allow field entries you do not want for validation reasons.
Look in the scripts in the example files that comes with FileMaker and study some of the scripts, it will become clear to you.
See, this is why I suggested asking the question in another forum: now we're going to get into a big discussion, and it's in the wrong topic area.
You're probably right that a lot of solutions start every script with error capture on, I've been guilty of this myself, but this is not a good practice, because it suppresses all error messages from the application, and do you really want to try to anticipate EVERY possible error? It's better, even though it's more work, to turn error trapping on only where you need it, then turn it off again, e.g. before and after a Perform Find step.
@iwrc: typically we use error trapping because FileMaker's native error dialogs can be confusing, and/or when we want a script to continue regardless of a condition we can easily anticipate, e.g., when a Find results in zero records found, or a user cancels Print.
Google is your friend, here's a recent article of possible interest:
The short answer : FileMaker has error codes, error trapping catches these error codes and suppresses them.
Why use error trapping : Most users dont understand FileMaker like a developer and need errors displayed in a language they understand, so you set the trap for "anticipated" errors, and display a message or do an action that is understandable.
Note: you need to understand what are the possable errors that will happen in your situation , hence the response from @fitch. Before you set traps you need to know what you want to catch.
EG: dont set a trap for Rabbits if you want to catch Fish
As to being important, you can make a functional solution without them, but it can be a better one with them.
As has been stated above, Set Error Capture On will suppress FileMaker's native error messages and allow you to handle them with messages more specific to your database and your situation. But it's also good to trap for situations that will NOT be judged bad by FileMaker, but will be judged bad by your users (e.g. allow a customer to pay for a sale on credit when the customer's record indicates he/she has been designated as "cash only"). I find I error trap for "business logic" at least as much as I trap for for stuff that FileMaker will complain about.
Ann Arbor, MI
I don't disagree with your point, but you're describing implementation of business logic. I think it muddies the water to call that error trapping.