The example I’m hitting is that I’m attempting to update a record in a database and I get a violation of a unique value constraint. The text of the message has the name of the constraint and the value that is duplicated. In principle, I could parse the text of the message to extract this information. But I hate to do that, because text processing like that has a tendency to add ambiguities. Like, the value is enclosed in parentheses. But if I search the text for parentheses, what if parentheses occur somewhere else in the message, like someone created a constraint name with parentheses in it or some such? What if future releases of the DB engine change the wording or format of the message? Etc. So is this information available in cleanly-defined fields?
(Specifically I’m using VB.Net but I presume any answer would apply to .Net in general.)
Processing the text data of the exception is the only way to do this currently. Granular information doesn’t come back in the exception.
While it would be nice to have this information come back, there’s usually not a whole lot that can be done about it from within code. Issues like simple foreign key violations should be accounted for in business logic to begin with, so things like this should be exceptional cases where you should provide the user with some way to deliver as much of the error message to the development team, anyway.