AntiPattern Name: GrenadeMessage

Type: 'Design'

Problem: 

Message objects are frequently used to let pieces of software communicate with each other.  One thread creates a message object, fills it out and puts it on a queue that another thread will get to at some point in the future.  Of course, these message objects need to contain some sort of context.

Take, for example, a conferencing system that has Conferences and Participants.  A new Participant connects to the system and a new Join Message object saying "hey, add this Participant to this Conference" goes onto the queue for that Conference.

Contexts: MessagePassing in low level messaging systems, such as PostMessage between threads in MicrosoftWindows.

Supposed Solution: Just use a pointer to the object.

Resulting Context: What happens if the Participant decides they don't want to talk to you and leaves before that Join object is processed?  The object doesn't exist, and you get a crash.  Can be hard to debug.

Applicable Positive Patterns:
* MessagePassingConcurrency: pass the ObjectByValue using a copy of the context instead of a reference. Alternatively, pass an object ID which can be validated (e.g. window handle).
* GarbageCollection: so that dangling pointers aren't a problem
* PublishAndSubscribe: if the service goes away, the unpublish action should clean stale messages out of applicable message queues
* ExceptionHandling - Will not work in this case, sorry.

----
'' I think this is not an Antipattern. With the NullPointerAntiPattern name, it would. This way it looks like a poor programmer wrote the message handler. ''
----

When passing an object pointer through PostMessage as a parameter to a non-system message (i.e., with an ID higher than WM_USER), the message sender cannot free the memory after posting the message.  Either the recipient must take ownership of the object, or other mechanisms must be used to free the memory. 

* ''Note that the receiver must explicitly take ownership, it cannot be implied. There is no guarantee that the asynchronous PostMessage will succeed. If the message queue overflows, the object will be dropped between the cracks.''
* * No, sorry. In that case, PostMessage calls SetLastError(ERROR_NOT_ENOUGH_QUOTA) and returns an error to the caller. ''It's possible, but unlikely, that a thread could terminate after a message has been posted to it but before it handles the message.  That's getting into a pretty small corner case on most systems, though.''

AntiPatternCategory: Development