Many times I saw people mentioning that it is not a good practice to throw and catch messages within a single process. Single Process Messaging (A throw sending a message to a catch inside of the same process) being problematic, but why? Could someone please explain, what could be the issues if we do so?
I see no issues besides the fact that it’s unnecessary complicated in many cases. Why not use a link event? Sometimes a real message event is necessary, e.g. if you want to send a message from a subrocess to the main process.
Building on what @fml2 said - indeed there are better events to use than messages for internal process communication.
It’s also against the BPMN standard. The standard itself says that messages much leave the scope of the process they where sent from, it also says that you can only receive messages that originate from outside the scope of the process. I suspect this is done ensure more clarity when reading the message event in a model. It makes things less ambiguous when you see a message event.
The process engine is not built or tested for this purpose, especially not for message correlation within the same process instance from delegation code that could be located anywhere (expressions, java delegates, custom plugins, etc). Especially if the triggered message is interrupting, the process engine would have to make certain checks (e.g. should I continue running the next steps after the code that sent the message?) that are just not there. And that’s where the behavior will become undefined. This is different to conditional events for example, where we have logic that takes care of such a situation.