Event-driven programming

What if instead of tightly controlling the run of a program, the software just sits idle until the user does something? In other words, the flow of the program is controlled by user-generated events.

The meat of event-driven programming is in the event-handlers. These are functions in the software that you call in response to certain events

This is probably the most important conceptual part of even-driven programming: the user is in control of your code. This has vast-implications on the type of code you write. For one, you can't expect the user to follow a predefined execution path (unless you go to great pains to enforce one). Instead, the system must be much more open-ended. This means more robust error-handling--you can NEVER assume the user has entered data in a certain order or processed one event over another, etc.

For an example, imagine a window that has two buttons. One of them lets you input an integer, and puts it on a stack. The other button adds every number on that stack. In a structured environment, you could go through a loop, inputing numbers, then adding them. If your program is event-driven, you can't assume a certain number of integers, you can't even assume that any integers have been entered at all.

That's a simplistic example, but it illustrates the fact that even-driven code must be robust enough to handle the results of other events--or, more commonly, what happens when other events haven't happened. Even-driven idioms are non-sequential.