They'll run the same way but I think the newer one is slightly more maintainable / easier to debug. And I'll admit in advance that this is splitting hairs.
But it's not about what the computer does, it's about what the code says to the developer who is maintaining it.
The new way makes it a little bit clearer that unless an exception is thrown, this function will return true. And if an exception is thrown, it will always return false. Thinking about the code this way just makes it easier to maintain, because it's a very simple and common pattern.
The old approach basically says, to the developer reading the code, "after executing the code in the try/catch block we'll find out whether to return true or false." Placing any code after the try/catch block (even one trivial line like "return true") implies that there's a reason to continue execuring after the try/catch. But there isn't. Moving the 'return' up above the 'catch' makes the simpler pattern easier to recognize and stick to.
Also, I just noticed that I screwed up the AddDebugMessage / AddUserMessage change. The "unable to initialize" message is something that belongs in the user log, but the exception call stack (exception.ToString()) belongs only in the debug log. I really don't ever want an ordinary user to see a call stack, because those are just noise to anyone who doesn't have a copy of the source code. EDIT: And I fixed that a minute ago.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
