I'm simply showing you why, yet again your all-knowing arrogant oppinions and your haste to spew copypasted code and invalid oppinions you are wrong, yet again. It's not a personal insult, with exception to the fact that you call yourself a programmer which is laughable at best. I recommend you go play with legos, because when facts hit the fan, you retreat into playing the victem and wondering why people stop to take the time to explain why you're wrong.
Let me break this down for you. I agreed that error handling is a good idea, but standing on the fact that I agreed with one of multiple points is like buying a broken clock and claiming that it's at least right once a day. The clock is pretty useless for the rest of the day, but I suppose we all take what we can get.
Handling all exceptions in methods that connect and send data is not correct, and here's why.
First of all, if you just blindly wrap your code in try-catch blocks, you will not get the exception stack which helps with debugging.
Second, multiple of these methods throw the exact same exception. So given that, your code flow consists of something like this:
try
{
connect;
send;
}
catch(...)
{
...
}
Now you want to be able to handle certain things properly depending on what happened. If you're sending multiple chunks of data, you want to know where the exception was thrown, and not being able to tell if it came from the connect call or the send call is problematic. If you can't see this, I don't really know what to tell you except go get some experience and we'll talk after. This is not acceptable, and as you said earlier, if you talk to any real programmer, they'll laugh. The point of exceptions is that you can handle exceptions at the point where they're thrown, and be able to reason and know exactly where they were thrown without just wrapping huge chunks of code in a block. Your suggestion that you also wrap a try-catch block around main is also quite absurd and shows that y ou have little to kno experience with the tools of which you speak. Again, you would have to know what to catch, and if exceptions are being thrown that far up the stack there's something wrong and it should be allowed to abort, not just be silently caught and thrown on the floor. This kind of programming makes debugging hard, testing hard, and hides errors that will present themselves during runtime which you could fix.
You state that the OP should use mutexes because there's a deadlock; this is stated as fact, not as a "you might want to do this":
"What your doing here is joining both threads together and executing them at the same time, but they're pretty much being given
access to the same data at the same time, causing a deadlock. And this is the first trip that most programmers, myself included, make when using threads:
accessing the same data at the same time among two or more threads."
There are various things wrong with this; first, that it's not posed as something to look into in the future, second that a mutex (especially in your code) is wrongly used, third that a mutex isn't used, and finally, you have some issues with your understanding of threads.
Calling .join on a thread is not "joining" a thread together. It simply waits for that thread to finish before exiting. Without this statement, the main thread will exit, thus terminating the other threads. You are not joining the two threads together, just blocking until they exit.
If you create two threads, thread a and thread b, and then do:
b.join()
a.join()
it will wait for b to finish; if b finishes, it will wait for a to finish. If a is already finished, it will return and thus the main thread can terminate.