Well, if you're talking about much, much more advanced games, rather than having an enemy react to the press of the button, you'd have the enemy's AI react to "seeing" the player armed with a knife, and "seeing" it would require that the player was in line of sight, and the enemy "inspected" the character, in terms of health/equipment/etc, and then based on the final determination, "angry" was what the enemy AI decided on.
ie: on each update-cycle (or every several, to save CPU), have each enemy that's in-range, check to see that they've still got sight of the hero and run a basic AI routine to choose their strategy, based on what they inspect.
If your question is more about what to do about an event which several things need to know about, in general...
ESC is to toggle "pause"/"main-menu" if you're in-game, but it's also used to back out of sub-menus, if you're in a sub-menu, setting options, or to close your character's stat/inventory screen in real-time, during gameplay.
So now you've got all of these things which need to know when ESC is being pressed.
Instead of tying them all together in one gigantic function with a boatload of conditional statements to work through what should happen...
...you should look into a pattern where various menus can
subscribe (or "register" or "listen") to the keypress event, and fire their own methods when notified about the event in question.
But with a little bit of planning, you can use the
Mediator pattern to create one "emitter" per type of thing that you want to listen to:
Say you have an
Input mediator, which listens for keyboard presses and mouse clicks, and deals with all of the hard stuff like timestamps and working out screen-coordinates and the rest.
Then, using a "subscribe" or "listen" method of input, each object interested in being notified will subscribe to something:
Then, when Input hears about a keypress and works it out to be the proper key, it will
notify (or whatever), all of the objects which have subscribed (and support the proper interface).
So now, if you're in-game, the game window can subscribe to
ESC to pause, and unsubscribe to
ESC once it IS paused (and subscribe again when it resumes). Other menus can subscribe to
ESC as soon as they're initialized, or "opened", or whatever (depending on if you want to create new instances every time, or use the same one), and unsubscribe when they're being closed.
Now your menus don't need to know about one another, and they don't all need to be a part of the same function/switch/whatever... ...they just need to know when to listen, and when to clean up after themselves.