You either use an error event handler or you tighten up your code.
Exactly! If you don't want to make an *error* event handler which closes the code gracefully on quit/cancel events, then your code needs to be written such that it expects and caters for those cancel events. The easiest way to go about this is to do what every experienced programmer should be doing in any case: make small atomic functions performing only one single task.
I.e. instead of opening and closing each dialog in one ginormous function, have a single function for each dialog. Then in each of those functions it either returns nil (to indicate cancel), some value (to indicate the input), or a nil/T for Cancel/Ok and setq the inputs to some other variable (though I don't like the later option - smells too much of using global variables, you could quote some arguments to these functions of course).
Then catering for such things as cancels is a very simple matter of wrapping all the calls to these dialog functions in an and. Something like this (using the idea of nil for cancel, else the inputs as a list of values):
;; Perform actions when user entered all data without any cancels, i.e. pressed the "OK" button in all dialogs.
)
;; Else if you need to do something on a cancel you can do it here, otherwise just don't put anything in this spot.
)
;; Any code which needs to happen irrespective if the user pressed cancel or not can go here