Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
aj_developer
Starting Member
2 Posts |
Posted - 2007-05-29 : 14:50:23
|
I'm creating a class that will wrap a SqlException and will offer the developer a way of determining how to proceed in handling the exception by offering a suggestion of retrying, revalidating the data, and/or calling the entire process a no go.One of the ways i've come up with to accomplish this is by using the severity (SqlException.Class) to assist in making a suggestion to the developer. I'm hoping to get some feedback from the developers who use this forum if they feel severity is or is not the way to go, and also to offer any other ways of accomplishing that they can come up with.ThanxAJ |
|
jezemine
Master Smack Fu Yak Hacker
2886 Posts |
Posted - 2007-05-29 : 19:43:01
|
why not just let them catch SqlException, inspect the members of the exception (such as Number, Class, etc) and handle it as they see fit? I guess I don't see what more information could your class provide besides the members already present in SqlException. www.elsasoft.org |
 |
|
aj_developer
Starting Member
2 Posts |
Posted - 2007-05-30 : 15:12:57
|
I appreciate the feedback. First of all, were looking to come up with standard DB Exception that not only allows us to wrap a SQLException but to throw a DB Exception even when a SQLException is not present. Secondly, were also looking to categorize exceptions in a way to give a developer a "suggestion" on how to proceed. You are correct however, it will ultimately be up to the developer to define how he will handle the exception.What I was looking for was if and how people felt about SQL Exception Severity and how they felt about it's reliability.ThanxAJ |
 |
|
jezemine
Master Smack Fu Yak Hacker
2886 Posts |
Posted - 2007-05-30 : 15:51:59
|
you could set myDbException.InnerException = mySqlException and then the devs could inspect the properties that way. you can't derive from SqlException because it's sealed.besides just the severity though, your devs will need more information to know if they should retry/ignore/abort. As I recall the Number property of SqlException will tell you which error it is - I would think that's one more you would need to check at a minimum. www.elsasoft.org |
 |
|
|
|
|