.NET Exception Handling lookup from a Table

My manager designed a table exactly like this

[Exception]

PK | ExceptionId

ExceptionCode varchar(100)

ExceptionDesc varchar(255)

ExceptionMSG varchar(255)

I'm using ASP.NET Webforms and using stored procedures/ADO.NET for DataAccess. Now 开发者_JS百科he does not want me to hard code validation in stored procedures nor in the code behind, but to catch the constraint exception message and look up the same error message in the database and look for the message that we want to show. I wonder if his design will work or should I explain to him that something is wrong here.

What do you think guys?

As such, there is nothing wrong in approach - actual error message strings will be stored in some store instead of hard-coding. The choice store out here is a database. The approach should work except I would suggest few things:

1. Error messages should be cached - I will prefer caching all messages in app start instead of on-demand caching.
2. You may have to hard-code some messages that deal with app start-up (for example, invalid database connection string etc)
3. Generally, the exception should look up the message string using some facade such as a IMessageProvider. In your case, IMessageProvider implementation would use a cache (dictionary) that was filled at app start from database. You can swap this implementation with something else easily (maybe loading from resource files etc). You may consider using IOC/Dependency Injection to supply appropriate message provider implementation to exception objects.
4. A typical message lookup implementation should have a fail-safe mechanism - for example, if the error code does not exist then it could use a hard-coded string such as "Some error (code: xxxx) has occurred, please contact your administrator". Ideally the user is not expected to see this message in a live system.

In my opinion, it seems a little silly to look up exception messages in a database, considering if the exception was database connection related, you wouldn't really be able to look up a message haha. It would make much more sense to me to have perhaps a configuration file (as a resource) on the web server that could be changed, rather then going to the trouble of connecting to a database. In all the ASP sites I've ever made, however, the developers take care to make meaningful messages in the Exceptions they throw, for validation especially.

I can see the desire for changeable messages; however, I think a database might be a little overkill. I could be wrong though... I just may not have encountered a situation that it makes the most sense for. However, if your manager absolutely insists on this, then I suppose you would have to make it work. I guess just be weary of the case where an exception is connection related. I hope this was helpful.