Currently, if the source generator internally throws an exception it swallows it. This adds value by allowing further source generation to continue, but it also means that one may not know that something failed in source generation. (Especiallly in an embedded build where so much log output can be generated that one will not routinely look at it.)
This Jira issue will be used to introduce exception throwing by the source generator, as controlled by a new configuration property to be added. The default behavior will be the current behavior. The CTF will use the new behavior, the better for detecting failures. The ANT task will have a new option added (something like the "failonerror" that the delete task has) if it doesn't already have something like that, again with the default behavior being the current behavior, for backwards compatibility.
Maybe we want two options, or maybe we want three options
1) Generate all source we can and swallow all source generation errors
2) Generated source but stop at the first error thrown
3) Generate all possible source that we can, complaining at the end if anything failed
My current opinion is that we want the last two but not all three, but the current behavior is #1. That is, if an exception is thrown currently, the current XSD stops processing. But code layers higher up don't receive an exception or other failure so they will continue on as if everything was successful. Because of this, maybe we do need three choices, and thus two new options:
1) Fail on first error: true/false
2) Return exception: true/false
and if #1 is false and #2 is true, then we would always return the FIRST exception thown, but not throw that exception until all other work as been completed.
The current code stops processing an XSD if an exception is thrown parsing that XSD, however. It just does a "return" instead of throwing that exception. Thus, "fail on first error" would only be meaningful if the XSD was successfully parsed but an exception was thrown while writing the source files to disk.