Catch InvalidProjectFileException Fixes #9394

[Forgind]

Fixes #9394

Context

InvalidProjectFileExceptions thrown by attempting to get the properties or items from an invalid project are not handled specially in XMake's big try/catch, which means they are caught as a generic "exception" and thrown as an unexpected internal error when in fact this should be an expected user error. This resolves that problem.

While poking at this, I happened to notice that if an error is logged, the next message is on the same line. I think it's better UI to move it to its own line, so that's the second commit.

Changes Made

Handle InvalidProjectFileExceptions as expected/user errors.

Add \n to errors logged by SimpleErrorLogger.

Testing

I tried the repro in 9394 and successfully reproduced the problem. I tried with this change, and it instead printed this:
[path]\invalid.proj(1,1): error MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 1, position 1.

in red. That looks good to me.

To see what other bugs I might uncover, I also tried adding /t to force it into the post-build version, but that failed in the expected way.

Then I (briefly) looked for other types of errors that might get thrown at this point. I saw internal errors (but that seems legitimate to be thrown as internal) and logger exceptions, but those are already handled. If anyone is aware of any other kinds of errors that might arise that I should handle, please do let me know.

Notes

[JanKrivanek]

Thank you!

[danmoseley]

Is this the right place too catch these? IPFE has been intentionally omitted from this location since the start.

[rainersigwald]

Feels wrong to me, too. Can you move the try/catch to the code specific to the new feature?

[Forgind]

Is this the right place too catch these? IPFE has been intentionally omitted from this location since the start.

What was the reason it was intentionally omitted? I just put it there because it was easy and seemed like an exception that shouldn't be turned into an internal error in any case.

Can you move the try/catch to the code specific to the new feature?

Regardless of the reason it was intentionally omitted, this is easy enough to do and is probably slightly better coding style. I can do it.

[danmoseley]

What was the reason it was intentionally omitted? I just put it there because it was easy and seemed like an exception that shouldn't be turned into an internal error in any case.

Possibly the principle that an exception should be caught at the point in the code that is best placed to do something about it but probably more to do with the fact it would make it easy to overlook specific exceptions coming from unexpected code paths.

[rainersigwald]

I think it's worth validating this with a test.

[rainersigwald]

I would still like to see a test, please.