Yep, you are definitely missing something. Gotos would typically be used, like you said, to perform a one-way transfer of control.

However, events do not do that. When the code fires the event, it knows full well that once event is published (or processed, queued, fired… etc) code execution will resume on the very next line in the code that generated the event.

The use of goto creates a very tight coupling between the code that calls that statement and the code that’s on the receiving end. Developer has to have intimate knowledge of both places in order to use goto.

On the other hand, code that fires events would typically not know or care who is interested in listening for that event. There could be a listener. Or there could be a 100 listeners or 0. Those listeners could be in the same program where event was fired, or they could be in a completely different application, or they could be on a different machine. As far as the publisher is concerned, as soon as he generates the event his job is done.

If you are with me so far, what I described above is the ideal case of pub/sub pattern. Unfortunately in the real world things aren’t always ideal and there are cases where publishers generates an event, a subscriber gets invoked, changes a whole bunch of state and by the time code execution returns back to the publisher “the world” appears to have been turned upside down. And I’m sure you’ve run into this in the past, because this condition often arises when pub/sub pattern is implemented in a very simple fashion (e.g. via use of delegates or events in C#, or function/interface pointers in C/C++).

But this problem isn’t necessarily pub/sub pattern but rather the implementation of it. This is why many systems rely on queues so that when an event is published, it is simply queued up to be invoked later giving the publisher a chance to finish execution while the world is still intact. When publisher is done doing it’s work, an event loop (aka dispatch loop) will pop off the events and invoke subscribers.

There are a couple of differences. First, when a code executes GOTO, it gives up control, and there’s no guarantee that it will regain control. A publisher in pub/sub, however, will keep running and performing its logic, sending off messages as appropriate. Its behavior is understandable and predicable.

Secondly, the subscriber will receive messages, and unlike with GOTO, the message itself carries context. Both the type of message, and any properties it carries, help tell the subscriber perform its role. And, after handling a message, the subscriber is still able to take new messages. So it’s behavior too is understandable and predictable.

The big difference is that the publisher and subscriber have a well-defined flow of execution, and they will, in essence, keep looping and doing their jobs, while sending and receiving messages. Code with GOTOs can be well-written and orderly, but it can also degrade, and there isn’t the same guarantee of clearly understood behavior.

You’re right, though. Someone could write a pub/sub system with so many messages and so many little jumps that keeping track of the processing flow could become a nightmare. And on the other hand, you could write a system with GOTOs that behaves extremely orderly and is easily understood. (I’m thinking of assembly code for very complex systems before symbolic languages took over.)

But typically, the decoupling you gain from pub/sub simplifies the problem of distributed processing and decouples logic within your system. Also typically, straight-up GOTOs tend to create complicated systems where understanding the flow of control becomes problematic.