|
I've just read Mr. Turini's article about exception-handling practices http://www.codeproject.com/dotnet/exceptionbestpractices.asp and I'm not quite clear on some things. I'm used to writing in C, with functions that return success/failure codes. While one must strive to avoid the temptation to simply ignore return codes, the use of success/failure codes allows code to progress sensibly when things don't work.
Suppose I'm reading in a bunch of dates (text format) from a file and I wish to convert them into a datetime format, using some default value if things don't work. Is there any practical alternative to writing a wrapper function to convert string->date, using a catch within the function to snag the dates that don't convert? If a generic "catch" is considered sloppy, is there a practical alternative to looking up every single function or conversion that might be expected to throw exceptions to find out exactly what exceptions it might return and risk having the application die if I miss one?
It seems to me that there are many situations, especially when accepting data from other sources, where failures are to be expected. My personal preference in such situations would be to use something akin to the IEEE floating-point NaN concept; if there's an arithmetic failure during an expression (division by zero, log of a negative number, etc.) return a sentinel value that will propagate through future expressions. Although a developer may sometimes wish for more detailed reporting of exactly why a complicated expression returns a NaN, most of the time the only thing that really matters is whether the expression evaluates or not.
Also, is there any good way in VB6 (since I'm still doing maintenance with that) or vb.net to make a program resume to the 'outer loop' when an error occurs, rather than dying altogether. If I have a button whose code is (VB6 style):
sub button1_click()
do_some_stuff()
a=sqr(-1)
do_more_stuff()
end sub
it would seem perfectly logical that the error in sqr() would prevent the program from running do_more_stuff(), but I see no particular reason the program shouldn't be able to try return to a state as though the button had not been pushed. To be sure, the program might not always work correctly after that point, but allowing the option to try would seem nicer than simply having it die totally.
|
|
|
|
|
Youre question is so broad that it's impossible to answer with anything shorter than an entire article. There's a bunch of different ways you can do this, all of which depend on your business rules.
You can start the loop and just process what you can up to the first error.
You can ignore errors for any lines and just keep going.
You can have the loop ignore errors and build a collection of processed objects, returning the completed collection.
Or you can create a collection that has both good data objects that passed processing AND exception objects for each one that failed.
Or you can create a loop that validates the data on each line without actually processing them and build a collection of exception objects for the lines that fail, ...
Or, ..., or, ..., or, ...
It depends entirely on your business rules and what you want/need to do with the good and bad lines in the data.
|
|
|
|
|
| It depends entirely on your business rules and what you want/need to do with the good and bad lines in the data.
Hmm... I just did a different query in the help file and found that the dateTime has a 'tryparse' method which does almost what I'm after, though the section of the help file on converting strings to other types didn't mention it for some reason.
I guess my more general question is what one is supposed to do if generic exception handlers are bad, if one doesn't really care about the specifics of any of the normal failure cases, and if there's no convenient way to determine in advance if an operation will work. If I allow the user to type in a number which should be in the range -1E250 to +1E250 and wish to validate it, must I look up the cdbl() function to determine what exceptions can be 'normally' thrown and then explicitly handle all of those? I would think it easier to make a little wrapper function:
function safedbl(st as string, defaultVal as double) as double
safedbl=defaultVal
try
safedbl=cdbl(st)
catch ' Who cares what went wrong?
end try
end function
but I understand generic catch instructions are frowned upon in such contexts. How else, though, can I validate the input to ensure that it will work?
If I didn't have to accept anything other than positive decimal integers, I could check to ensure the string contained only digits and wasn't obscenely long. I suppose the 'like' operator could probably used to individually check for all valid numeric formats, but that seems rather a waste. What's the 'right' approach?
|
|
|
|
|
Yes, catch-all Try/Catch blocks are frowned upon. Generally, people who use them just eat the error and don't report it, then wonder why their code doesn't work.
Yes, you should be looking up methods and function to see what exceptions they can throw. Then you can write your code to handle those specific cases. Generally, just trapping the root Exception class is a bit expensive because the Try/Catch block first sees if there is a handler for the specific exception. If there isn't one, then it looks to see if there is a handler for the parent class of the exception, and so on up the inheritence chain until it reaches the base Exception class.
I really don't recommend using the CDbl function anymore when Double.Parse and Double.TryParse are available. You get a bit more robust capability with the .NET conversion and type classes. For instance, Double.Parse will throw one of three exceptions if the value cannot be parsed into a double. Double.TryParse will never throw an exception, but instead returns a True/False value to indicate of the value was successfully converted or not.
You normally don't check the text representation of number for the correct format first. You try the conversion, and if it works, you then validate the returned number for proper range. If this entire process doesn't work, then your code can throw it's own exception. Seeing if a string will successfully convert to a number, regardless of localization, isn't really practical. You're trying to avoid having the conversion throw an exception, when that should not be your focus. You should be TRYING the conversion, then either throw your own exception if the conversion fails, or returning the validated value of the conversion.
It sounds like you're trying to do the conversion and validation backwards. It's far easier to validate the data in its native type than it is to validate it as a simple string. Convert the data to it's native type first, and if that works, validate the converted value. If that passes, then you've got a good value. But if either of those steps fails, then your conversion code should throw it's own exception.
|
|
|
|
|
Perhaps VB.net's documentation should mention double.tryparse in its section on conversion functions? The double.tryparse sounds very useful.
I certainly agree that trying to process something to see if it works often makes more sense than trying to pre-validate it, especially with things like dates (where validating requires just as much work as doing an actual conversion). I'm a bit paranoid, though, of being bitten because an object throws an exception for a case which is harmless but I don't happen to explicitly handle.
If double.tryparse didn't exist, what problem would there be with a function that called cdbl() and (except for setting a return value) just ignored any exceptions? Is the hazard that there may be exceptions whose consequences go beyond the conversion at hand?
BTW, forgive me if this is a FAQ, but is there a way to handle multiple types of exception within a try/catch block?
|
|
|
|
|
Try
.
. (code)
.
Catch fnfE As FileNotFoundException
' handle FNF case
Catch dnfE As DirectoryNotFoundException
' handle DNF case
Catch ioE As IOException
' handle general IO exception
Catch ex As Exception
' Rethrow anything else that happens
Throw ex
Finally
' any cleanup code that must execute no matter what happens goes here
End Try
|
|
|
|
|
If several cases use the same code, is there any way to consolidate them?
|
|
|
|
|
ADO.NET maintains an open connection to the server, even if your code closed it. This is so that the next connection that uses the same connection string can be made faster without having to rebuild the entire connection with the SQL server. This is called "connection pooling".
If the "closed" connection in the pool goes unused, it will eventually be dropped. I think the default is 15 seconds, afterwhich the connection is SCHEDULED to be dropped. It might not drop right away.
You can force the connection to be dropped yourself if you call the ClearPool method after you close your connection:
Dim conn As New SqlConnection(...)
.
. Do your database query stuff...
.
conn.Close()
conn.ClearPool()
Or you can specify the Pooling option in the connection string to tell ADO.NET not to pool that connection:
Persist Security Info=False;Initial Catalog=Northwind;server=SomeServer; Pooling=False
|
|
|
|
|
Brain oerating very slowly today, may need more coffee or something but in the mean time I am receiving a byte from a piece of hardware something like "1A" I need to reanslate it to 01.10, for a revision, got a slick way of doing it without masking off bits and such? This woudl be in Visual Basic 6
M
|
|
|
|
|
If you're receiving that byte as a byte and not a string, then you have to do the math (masking) to get the nibbles you want. If a string, it's simple string manipulation functions. There is no "slick" way of doing this.
|
|
|
|
|
Not slick, perhaps, but ((i \ 16).ToString & "." & (i Mod 16)) doesn't seem too bad, does it?
|
|
|
|
|
It depends on how the data is comming into his app, either a real byte or a string. If it's a real byte, then yes, it works. If it's a string that just looks like "1A, then it won't work.
Also, he's using VB6, so ToString is out of the question. I also can't remember if "\" is a valid operator in VB6. It is in VB.NET.
|
|
|
|
|
The "\" operator does exist in VB6. Very useful, especially since VB6 real->integer coercion rounds rather than truncates.
The VB6 str() function will convert a number to a string, but adds a leading blank if the number is positive. I think cstr() or cstring() will convert without the leading blank.
BTW, is there any good built-in function to convert an integer to a two, four, or eight-digit hex string? It would be nice if the hex() function allowed one to specify the number of digits, but alas it seems not to.
Incidentally, a warning for people using "val()" to convert hex data to long: using val("&h" & string) will yield bogus results with values in the range "00008000" to "0000FFFF". You must use val("&h" & string & "&").
|
|
|
|
|
supercat9 wrote: BTW, is there any good built-in function to convert an integer to a two, four, or eight-digit hex string?
No, there isn't. Hex will return a string of the minimum length required to display the converted number. It's easy enough to build a function though. All you have to do is pass in the value and the number of digits you want, then use Hex to convert the value to it's Hex representation, create a string with the proper number of 0's in it minus the length of the Hex string and stich the two together.
|
|
|
|
|
It's easy enough to build a function though.
That's what I've done and can continue to do (defining hex2, hex4, and hex8 functions). I didn't want to reinvent the wheel if it had already been done, especially since computing hex8 requires generating three temporary strings. Probably not a huge performance hit, but not exactly elegant, especially since such functions are needed often enough they should have been in VB in the first place.
|
|
|
|
|
supercat9 wrote: (defining hex2, hex4, and hex8 functions).
Why?? Why not just write a single function that take the number of places as a parameter??
supercat9 wrote: since computing hex8 requires generating three temporary strings
Why?
|
|
|
|
|
\ is a valid operator in vb6
|
|
|
|
|
It's been sooooo long since I've touched VB6. Thankfully...
|
|
|
|
|
ya i still have to on occasion 
In the past I used it to know if a number was even.
If Val \ 2 = Val / 2 Then
'even
Else
'odd
End If
|
|
|
|
|
When my programme starts I first display a login screen and then if the right user and pass are entered I open my main screen.
Untill now I'v been hiding the login screen (and it works fine) but I would like to close it.
Since this screen opens another form it gives an error:
An attempt has been made to free an RCW that is in use. The RCW is in use on the active thread or another thread. Attempting to free an in-use RCW can cause corruption or data loss.
anyone know how I can close the login screen (who is the startup form) and open another form.
I don't want to open my main form and open the login ontop (showdialog).
any help will be apriciated
If my help was helpfull let me know, if not let me know why.
The only way we learn is by making mistakes.
|
|
|
|
|
Don't make your Login form the startup form. Instead, create your own Sub Main and set your applications startup object to that.
In there, you'll launch your login form where you get the user credentials and authenticate them. Your form should then kill itself (Application.Exit) returning control to your Sub Main.
In your login form, you can expose some properties that tell if the user was successfully authenticated and a property or two identifying the user.
In your main application form, you can create a Sub New that takes the user credentials as parameters, or whatever else you want.
<STAThread()> _
Shared Sub Main()
Dim loginForm As New LoginForm()
Application.Run(loginForm)
If loginForm.Authenticated Then
Dim myApp As New MainForm(loginForm.Credentials)
Application.Run(myApp)
End If
End Sub
|
|
|
|
|
I'm developing a programme where the user needs to login.
How it should work:
the programme starts and makes a connection to the db (with a standard user and pass) reads the table users and puts that table into a datatable.
once the user has provided his login and pass (and they exist) a new connection to the db is made with the his login and pass (they are created in SQL server), after this only the users connection is used to access the db (that way we can always know who is connected)
this all works and the programme works fine but when I check the connections to the db (in SQL server) it says that there are still 2 connections (per user). Now I don't like this  since this programme is going to be used by 10+ users that would mean there are already 20+ connections (I know that that is now problem for SQL but it just isn't how it is supposed to work) and there are also many other db's hosted onto the server so the less connections the better.
following is the code that I use to get the users from the db:
Public Shared Function ExecSqlInDatatable(ByVal Sql As String, ByVal connstring As String) As DataTable
Dim dt As New DataTable
Try
Dim da As New SqlDataAdapter(Sql, connstring)
da.Fill(dt)
'da.Dispose()
'da = Nothing
Return dt
Catch ex As Exception
MessageBox.Show(ex.Message)
End Try
Return dt
End Function
this code works but the connection to the db is maintained.
Any idea why??
Adding the da.dispose and da = nothing didn't help (that's why they are in comment)
any help/idea would be appriciated
If my help was helpfull let me know, if not let me know why.
The only way we learn is by making mistakes.
|
|
|
|
|
TDDragon wrote: this all works and the programme works fine but when I check the connections to the db (in SQL server) it says that there are still 2 connections (per user).
Yes, it is the connection pooling. It is faster to get an existing connection out of the pool than create a new one, so once a connection is created for the first time it will be returned to the pool once it is finished with.
TDDragon wrote: Now I don't like this since this programme is going to be used by 10+ users that would mean there are already 20+ connections (I know that that is now problem for SQL but it just isn't how it is supposed to work) and there are also many other db's hosted onto the server so the less connections the better.
It sounds like what you actually need is some sort of service interface to sit between your application and SQL Server (in order that you are only using one pool of connections to the database). If performance isn't so critical you can look at turning the pooling off (Not something I can remember how to do - it's been a few years since I last looked at that)
|
|
|
|
|
How read a barcode from scaner?
Plz Help me.
|
|
|
|
|
Hi
You Need an object that connect to barcode device
and usually have an event for alert to you when action.
that object Depend on device
you would provide that from manofactor of device
contact by barcode company
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
