Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations John Tel on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Catching Oracle exception erros in VB.NET
- Thread starter simdan42
- Start date
- Thread starter
- #3
- Thread starter
- #5
Try
.....What you want to do.....Write the code yourself....
Catch ex as OleDbException
.....Trap the error here......You write the code.....not doing it for you!
Catch ex as Exception
.....Trap all other errors here.....still not writing the code for you......
Finally
.....Close the db connections and other cleanup code if you need it.....
End Try
This is a help forum, not a let's do your work for you. You asked the question, I gave you the answer.....
Craig
.....What you want to do.....Write the code yourself....
Catch ex as OleDbException
.....Trap the error here......You write the code.....not doing it for you!
Catch ex as Exception
.....Trap all other errors here.....still not writing the code for you......
Finally
.....Close the db connections and other cleanup code if you need it.....
End Try
This is a help forum, not a let's do your work for you. You asked the question, I gave you the answer.....
Craig
- Thread starter
- #7
Thank you, however there is no need to get nasty. I was not tring to get you to write the code for me, How could you without knowing what the nature of what the error is. It your first posting you just said "Catch ex as OleDBException" you said nothing of a Try, Finally, End Try and where the error messages or other code went. Having never used the try block before I just wanted to know the correct syntax and the proper way to use the new information. Well anyway I got it to work and I thank you.
Hi
I am doing something similar in a project at the moment, and I prefer to return a custom error code from the stored procedure. In other words, you still have to use exception handling in your vb app because there may be other problems (connection could not be established, or some of the parameters for your stored proc could not be set up correctly). But if one of the exceptions you are likely to encounter is a data layer exception (eg primary key invalidated on a table) then you might be better trapping this in the stored proc itself and returning a custom error code back to your app, along with a string explaining, in user terms, what the error was.
Just an idea - doing all your exception handling in the application may work just as well for you.
Mark![[openup]](/data/assets/smilies/openup.gif "[openup] [openup]")
I am doing something similar in a project at the moment, and I prefer to return a custom error code from the stored procedure. In other words, you still have to use exception handling in your vb app because there may be other problems (connection could not be established, or some of the parameters for your stored proc could not be set up correctly). But if one of the exceptions you are likely to encounter is a data layer exception (eg primary key invalidated on a table) then you might be better trapping this in the stored proc itself and returning a custom error code back to your app, along with a string explaining, in user terms, what the error was.
Just an idea - doing all your exception handling in the application may work just as well for you.
Mark
Simdan42 -
I can see why Craig0201 got a little testy - you used the word "catch" in your original question, so we all thought you knew all about the try..catch..finally block (I did too until I read further).
If I might suggest, rephrase future questions to be more like: "What's the best way to handle exceptions in my Oracle calls?" It's a little more open, and you'll probably get better answers that way.
Custom24 -
You're correct in that it's often better to return an error state when you think an error is somewhat expected. Unexpected errors are, well, unexpected. You should always have a try..catch block at the head of your program to catch any System.Exceptions that might have gotten through lower-level try..catch..finally blocks, so that your users aren't presented with the default .NET "your program has crashed" dialog (so unprofessional looking!)
Catching exceptions is pretty cheap (CPU wise), but throwing exceptions is very expensive, so a general idea is to catch exceptions as low in the call chain as possible, and return status variables to the caller.
Chip H.
I can see why Craig0201 got a little testy - you used the word "catch" in your original question, so we all thought you knew all about the try..catch..finally block (I did too until I read further).
If I might suggest, rephrase future questions to be more like: "What's the best way to handle exceptions in my Oracle calls?" It's a little more open, and you'll probably get better answers that way.
Custom24 -
You're correct in that it's often better to return an error state when you think an error is somewhat expected. Unexpected errors are, well, unexpected. You should always have a try..catch block at the head of your program to catch any System.Exceptions that might have gotten through lower-level try..catch..finally blocks, so that your users aren't presented with the default .NET "your program has crashed" dialog (so unprofessional looking!)
Catching exceptions is pretty cheap (CPU wise), but throwing exceptions is very expensive, so a general idea is to catch exceptions as low in the call chain as possible, and return status variables to the caller.
Chip H.
- Status
