Question How To Handle This Exception

[mzeezee]

Dear Friends


I am trying to use EXCEPTION HANDLING for the first time. I have used the following code in my program:

        Dim checkvalue As Boolean = False
        Try
            checkvalue = SaveImOrder()
            checkvalue = SaveImOrderDetails()
        Catch ex As Exception When checkvalue = False
            Exit Sub
        End Try
        (Rest of the code)

In above mentioned functions I am actually saving records in tables and in case of any error returning "FALSE" back here ... Then I need to catch this FALSE value to exit SUB .... However the code is not working and I am unable to track my mistake .. Please help or advice something better


Best Regards


ZEE

 

[JohnH]

and also creates a dialog pop-up for the user giving the user the choice to continue or close the application?

A third choice is 'restart', often better than to continue in undetermined crash state.

I have plenty of Application.DoEvent() calls

Another one to avoid in most cases, but that a different topic than what this thread is about.

 

[jmcilhinney]

A third choice is 'restart', often better than to continue in undetermined crash state.

Indeed. Exit and Restart are the two options that I provide. If a client says that they want to be able to continue in that situation then I say that I can't support the app because I'm not going to try to track down bugs that may have resulted from an invalid state when an unknown exception occurred, possibly in a session some time ago.

 

[Rob Sherratt]

I think that we're getting a bit off-topic now.

Granted! Which section would be appropriate for such a question to be asked? Thanks.

 

[mzeezee]

Hi


Thank you all for your precious time in explaining Error Handling in such a detailed manner. After going thru all responses here and other sites I have decided to simply remove Error Handling and use IF-THEN statements. My code is now as follows:

Dim checkvalue As Boolean = False 


'Reverting previously saved records
If ImOrder_edit = True Then 
	checkvalue = ObjOrder.Get_Detail_DeleteByControlId() 
	If checkvalue = False Then Exit Sub 
	' 
	checkvalue = ObjOrder.Get_Control_Delete() 
	If checkvalue = False Then Exit Sub 
	' 
	checkvalue = ReverseItemsQty() 
	If checkvalue = False Then Exit Sub 
End If 
'
'Saving new records
'
checkvalue = SaveImOrder() 
If checkvalue = False Then Exit Sub 
' 
checkvalue = SaveImOrderDetails() 
If checkvalue = False Then Exit Sub

Best regards,


Zee

 

[Rob Sherratt]

Hi Zee,

Out of interest, how do you provide error reporting in the situations where your Functions return "False". Do the functions each call a common error reporting handler? Do you log the messages to a disk file or to a textbox? If you log to a disk file, then at what point does the error logger decide to close the file and terminate your application?

As for me, I will never again post a code snippet on this forum with a Try ... Catch ex As Exception block in it. Once bitten, twice shy as they say ! I will revisit some of my other posts and delete the exception handling code, lest I should be guilty of engendering bad habits again in future!

I still think that Microsoft should remove this type of exception handling from all their "exemplary" code on the Web. Because, well, it's not "exemplary" if it is "wrong" is it? How shall "we of little faith" avoid being "led into temptation" when the "saints" are publishing their "sinful exploits" for all of us to follow?

Thanks,
Rob

PS consider the following suggestion:

If Not ObjOrder.Get_Detail_DeleteByControlId() Then Exit Sub
If Not ObjOrder.Get_Control_Delete() Then Exit Sub

' etc

I think the procedure at which an error situation is encountered should provide the diagnostic data to the error logger, and thereafter the "False" status ripples up the stack as quickly as possible without additional error reporting. After the nested calls have all popped of the stack, and any event handler has exited, the top level task scheduler then prompts the user, closes the error log file, and terminates the application etc. Is that your policy also? I say this not as an "expert" but just because I have had to think this through and this is what I am starting to write now. There are unfortunately a very large number of changes to make in my application software due to my previous Try ... Catch ex As Exception blocks being used extensively in every one of over 350 Functions and Subs.

I "blame" Microsoft for leading me into sin by their examples

 

[mzeezee]

lol @ Rob Sherrat .... yeah MS lead me as well to the wrong direction with their examples ... anyway I must have to go through error handling and logging stuff on web in more detail ... right now I am simply calling a global function to execute sql statements and there I have applied TRY-CATCH block simply to avoid abnormal shutdown of my application .. since the application is still in development mode I haven't applied error loging yet, but in future I ll do it for sure .. secondly in case of several inset/update routines simultaneously I also have to write REVERSAL routines in case of error in any of the tables ...my current function of execution and error handling is as follows:

[COLOR=#2A2A2A][FONT=arial]Public Function DML(ByVal sql As String) As Boolean [/FONT][/COLOR]
[COLOR=#2A2A2A][FONT=arial]Dim cmd As New OleDbCommand [/FONT][/COLOR]
[COLOR=#2A2A2A][FONT=arial]Try [/FONT][/COLOR]
[COLOR=#2A2A2A][FONT=arial]    cmd.CommandType = CommandType.Text [/FONT][/COLOR]
[COLOR=#2A2A2A][FONT=arial]    cmd.CommandText = sql [/FONT][/COLOR]
[COLOR=#2A2A2A][FONT=arial]    cmd.Connection = GetConnection() [/FONT][/COLOR]
[COLOR=#2A2A2A][FONT=arial]    cmd.Connection.Open() [/FONT][/COLOR]
[COLOR=#2A2A2A][FONT=arial]    cmd.ExecuteNonQuery() [/FONT][/COLOR]
[COLOR=#2A2A2A][FONT=arial]    cmd.Connection.Close() [/FONT][/COLOR]
[COLOR=#2A2A2A][FONT=arial]    DML = True 
[/FONT][/COLOR][COLOR=#2A2A2A][FONT=arial]Catch ex As Exception [/FONT][/COLOR]
[COLOR=#2A2A2A][FONT=arial]    MsgBox(Err.Description) [/FONT][/COLOR]
[COLOR=#2A2A2A][FONT=arial]    DML = False [/FONT][/COLOR]
[COLOR=#2A2A2A][FONT=arial]End Try [/FONT][/COLOR]
[COLOR=#2A2A2A][FONT=arial]End Function
[/FONT][/COLOR]

For this function do you have any advice/suggestion?

Best Regards

Zee

 

[jmcilhinney]

If you want to make several changes to a database as a group, i.e. either all succeed or all fail, then you use a transaction. Each ADO.NET provider has a corresponding transaction class, e.g. OleDb provides the OleDbTransaction type. A transaction is associated with an open connection and then all actions performed over that connection are wrapped in the transaction. When you complete all the actions you commit the transaction. If an error occurs at any stage you roll back the transaction.

The commit goes at the end of the Try block. The roll back goes in the Catch block. You close the connection in the Finally block, which is where all code goes that needs to be executed regardless of whether the actions in the Try block succeed or fail. The code in post #21 is faulty because the connection will never be closed if an exception is thrown.

On a different note, the old VB6 style of returning a value from a function by assigning a value to the function itself is generally frowned upon in VB.NET. The proper way to return a value is with e Return statement.

 

[Rob Sherratt]

Hi Zee,

I've been down the same route as you with cmd.ExecuteNonQuery().
I am amazed (in an unpleasantly amazed way) at the number of possible different App Exceptions it can throw.
I must have experienced over 400 different ones, each time I "solved" one problem then another one was miraculously "revealed".
I found the documentation to be very sparse. There is no guidance on the sort of things that can go wrong.

Here are some things I learned as a result of exceptions being thrown:

a) You can not pass the period "." character or space character to SQL in any column names, there is no escaping mechanism
b) In your user data, there are a whole load of characters that are interpreted as "special characters" and which cause errors.
c) In your user data you have to parse it and change special characters like "tab" to "\t", "new line" to "\n" and so on.
d) In user data there was no way I could find to pass more than 4,000 characters.

Eventually after 4 days of this, one problem after another, I am embarased to admit that I "gave up".
I ended up purchasing developer rights to the commercial library from xPort Tools Inc
If you search for my other posts you will find the details.
Anyway, I am now recovering my sanity after cmd.ExecuteNonQuery() nearly ended it.

Regards,
Rob

 

[jmcilhinney]

Hi Zee,

I've been down the same route as you with cmd.ExecuteNonQuery().
I am amazed (in an unpleasantly amazed way) at the number of possible different App Exceptions it can throw.
I must have experienced over 400 different ones, each time I "solved" one problem then another one was miraculously "revealed".
I found the documentation to be very sparse. There is no guidance on the sort of things that can go wrong.

Here are some things I learned as a result of exceptions being thrown:

a) You can not pass the period "." character or space character to SQL in any column names, there is no escaping mechanism
b) In your user data, there are a whole load of characters that are interpreted as "special characters" and which cause errors.
c) In your user data you have to parse it and change special characters like "tab" to "\t", "new line" to "\n" and so on.
d) In user data there was no way I could find to pass more than 4,000 characters.

Eventually after 4 days of this, one problem after another, I am embarased to admit that I "gave up".
I ended up purchasing developer rights to the commercial library from xPort Tools Inc
If you search for my other posts you will find the details.
Anyway, I am now recovering my sanity after cmd.ExecuteNonQuery() nearly ended it.

Regards,
Rob

Most of what you're talking about is nothing to do with ExecuteNonQuery, hence the fact that the documentation for that method doesn't provide information about those issues. ExecuteNonQuery passes a SQL statement off to the database to be executed. What happens at the database is nothing to do with that method. Just about every database has an OLE DB provider so how could the MSDN documentation for ExecuteNonQuery document every possible error that could occur on every single database? If an error occurs at the database then an OleDbException is thrown and it's up to you to interrogate that to determine the server-specific error state. If you want to use a database with your .NET application then it's your responsibility to know what is valid SQL syntax for that database and what isn't. Every database provides such documentation.

 

[mzeezee]

If you want to make several changes to a database as a group, i.e. either all succeed or all fail, then you use a transaction. Each ADO.NET provider has a corresponding transaction class, e.g. OleDb provides the OleDbTransaction type. A transaction is associated with an open connection and then all actions performed over that connection are wrapped in the transaction. When you complete all the actions you commit the transaction. If an error occurs at any stage you roll back the transaction.

Thank you very much for such a valueable advice ... I should have to search and learn about Transaction class and its use ...

The commit goes at the end of the Try block. The roll back goes in the Catch block. You close the connection in the Finally block, which is where all code goes that needs to be executed regardless of whether the actions in the Try block succeed or fail. The code in post #21 is faulty because the connection will never be closed if an exception is thrown.

Thanks for mentioning this logical error .. I will just update my code accordingly ...

On a different note, the old VB6 style of returning a value from a function by assigning a value to the function itself is generally frowned upon in VB.NET. The proper way to return a value is with e Return statement.

Well I am a bit confused on this RETURN concept .. just ignored it for a while to deal with other issues ... Actually I am a VB6 programmer and recently has started learning and at same time developing a small ERP project as a part time so due to lack of time I have to skip several issues for later investigation ... but I must APPRECIATE people like you for your time and valueable advices ... I got several new points to work on just thru this post .. hats off to you