Maximum PC

Why on earth would you bother with a try/catch block if you are going to have an empty catch?

Dunno. FWIW, I think it's just so that even if you do nothing, people reading you code know that there is a potential for the code to not work right. Consider:


If the try {} block throws a FileNotFoundException, the str.chatAt(0) statement will throw a NullPointerException. Reading the code, you can see that the try {} block can throw the exception, even thought you do nothing with it. Compare that to:


When the str.charAt(0) line throws the exception, you would be completely mystified.

Although sometimes it is completely pointless.

I sometimes use those to swallow errors that I know I don't care about. Then again, I do put a comment there stating that it does nothing on purpose.

I spoz I can understand that but, why would you have errors that you "just don't care about" I mean, there is a reason for it right?

There isn't a comment and I can't see any reason why it shouldn't be handled. Especially because it is preventing this app from loading.

Also, why would you use a uid/guid for an index? Or have indexed values be full text strings? Searching a table with 1.5 million records is slow enough as it is.

I try to never, ever use empty catch statements. For one, C# doesn't handle it well (it assumes that catch {} is a catch(System.Object e) {}), and it's just bad logic.

As part of my everyday frustration, I actually saw this in a production app that one of our consultants wrote (before they hired me):




Yes, they're using it for type checking in a string. Why they didn't use RegEx is beyond me (since it's coming from the user, anyways). Exceptions should always be handled - if you see an exception you think needs to be caught, catch and treat it.

As far as GUID's are concerned, I use them when I know I'm dealing with databases that are going to deal with large sets of data (100 million rows and more). I worked in a bank where the transactions table was over 1TB in size and had millions of rows. BIGINT couldn't handle it, as we were getting 1,000,000+ transactions a day (we did archive every two years, but still).

Seems that developer doesn't know what the MSDN is or how to read documentation or ::gasp:: use Google.

http://msdn.microsoft.com/en-us/library/ch92fbc1.aspx


You really used GUIDs for 100M rows? Ew... I mean, There are much better ways to do it I would think. Multiple column PKs?

Even when indexed, GUID values are difficult to search on, and by difficult, I mean stupidly slow.

You'd be shocked at the level of incompetent devs out there. My brother in law was telling me about their 'consultant' writing ridiculous levels of code to do the same thing that DropDownList.SelectedValue can do. He said he cleaned up close to 100 lines of code and merged it to


For me, it's just easier on the eyes (plus DB design is not my forte).
I'm not worried about overall performance, however, and the one time I did see GUID's being used in large datasets, it actually performed quite well (PK's are GUID columns and was clustered). I didn't think too much of the performance the code had more issues than the DB.

You can use empty catch blocks for non-crucial components of your program. Ive also used it where i should have used continue in for loops, just makes it nice and neat. Consider this method I wrote a while back:



What can I do if I cant delete that cookie? Ignore it, that all.

At the very least, errors should be caught and written to the log so that it can be tracked. If you think you can ignore it in 1.0, remember that you might need to do something with it in 1.3 and with the logs, you'll know where to find the problem.

As for using try .. catch blocks to escape any looping construct .... ugh.

There's a few problems with using try/catch for this very reason. 1) You're spawning n calls to the system. This adds a performance hit to your application due to the number of try/catch calls the framework has to make. 2) It seems lazy and myopic. If you're using try/catch blocks to handle code in a normal program that you can otherwise get around with using non-try/catch blocks, it seems like you're wasting resources for that reason.

Also, for your example, while I understand if your app requires this exception, however, I would change a few things:

1) Use IsolatedStorage instead of using standard storage calls. IsolatedStorage in .NET can be done on a per AppDomain or per user basis. If you need/want to segregate cookies on a per user basis, IsolatedStorage is your class.

2) Isolated Storage gives your app full rights to that storage mechanism. So you can forego using try/catch to ensure that a cookie is deleted. Also, this is kind of nice because it's easier to troubleshoot when a file can't be read or can't be deleted.

3) No need to worry about permissions on the system since IsolatedStorage is per AppDomain/user.

Amen, brother. While there are exceptions to the rules, people need to follow the rules first before creating an exception.

I mean, if you can't do this:



I don't want to know what the rest of the app looks like! A friend of mine corrected this, otherwise, bad behavior from me. He called me out saying "being creative is not an excuse for not knowing the framework." Some people do it because it's easy and doesn't require knowledge of the framework. To me, I see that as lazy.

I dislike "lazy" stuff. Sometimes, I am lazy though.

I love being lazy, but that doesn't mean my code has to be. I just despise looking at code that, for the most part, is poorly thoughtout. The framework exists to make life easy, so if you don't use the framework...well.

What bothers me to NO END is when people use try{} and catch{} when the program is LESS THAN 100 LINES. Those try/catches are useless in such a small program as bugs should be easy to find.

If you can't write dependable code for a small program in the first place in small programs you have an issue. Try{} catch{} should never, ever be used when displaying example code when the try/catch has absolutely nothing to do with the concept. It muddles your code for no reason at all.

Those were system wide cookies, internet explorer's cookies.

In .net, i am not ware of a trydelete method - something that will delete all files it can without stopping on the first error.

my method works

Try / Catch blocks are NEVER useless. It doesn't matter if it is 100 lines or not. What if you are doing file stuff? You want your application to crash because it can't find a file? Of course not you want it to give you a message and / or recover if possible.

Try/Catch is good practice and should always be used around nearly 100% of the code you write.

If you can't look past this, and see the "example" in the example code. Stop programming. Put down the compiler and walk away.

Just because it works doesn't mean that it is correct or that it is what you should do. Listen to the good advice you have been given. You'd be wise to listen to the experience.

I hate "arrogant" programmers. Add that one to my list of programming frustrations

Try / catch blocks are not used for bug finding. They are used to handle exceptions. A small program can have many uses to catch exceptions. It really has nothing to do with 'dependable' code.

I'm not sure what you mean by 'displaying example code', though .. could you clarify your point?

A good example would show how to handle the exceptions involved.

try/catch is useless when you're using it wrong. try/catch is not limited to the number of lines of code, but is limited to the functionality you want to achieve.

Also, try/catch are exception handlers which is different than bug-hunting (or debugging). Exception handling deals with run-time errors: errors your app can't handle like system level errors such as file handling, network handling, etc.