This is kind of a "big question" :-/ It depends partly on how complex the script(s) are (and how many people might be using it, and/or the data involved). I am, in many ways, not the best person to answer, however, since I am currently the only one answering…
There is more than one way|part of this. Lets start with the basic tool, which is the script step: Allow User Abort [Off], the opposite (which is the default), Allow User Abort [On] (both are checkbox choices). If it's set to [Off], then users cannot stop the script by using the Escape key (or, on a Mac, Command-Period).
So, you could use [Off] in your script so that some steps could not be stopped, then turn it back [On] afterwards. So it would at least finish critical parts. What to do about the data afterwards is a more difficult problem.
Another method is called "Transactional Scripting", which as been around since FileMaker 7, but become very important when FileMaker Go came out, as Go can loose connections more often. Its basic method is to do field changes within a portal. FileMaker treats portals differently. If you stop such script steps it will revert the fields back to what they were, if such happens before you commit the record. Something like that; I don't know much more. [ I see it also uses a "Revert Record/Request" script step, to handle all changes of the record (and its portal).]
......if canceling from within a loop, one could do as appropriate, Halt Script, or maybe Exit Script (hope this helps):
If [ Get ( ActiveModifierKeys ) > 0
Perform Script [ “CleanUp” ]