Quantcast

Maximum PC

It is currently Fri Aug 29, 2014 12:11 am

All times are UTC - 8 hours




Post new topic Reply to topic  [ 43 posts ]  Go to page 1, 2, 3  Next
Author Message
 Post subject: Your programming frustrations
PostPosted: Fri Apr 03, 2009 6:43 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
Why on earth would you bother with a try/catch block if you are going to have an empty catch?


Top
  Profile  
 
 Post subject:
PostPosted: Fri Apr 03, 2009 7:07 pm 
Little Foot
Little Foot
User avatar

Joined: Mon Jul 28, 2008 1:39 pm
Posts: 123
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:
Code:
String str = null;
try {
   File f = new File("file.txt");
   Scaner inFile = new Scanner(f);
   str = inFile.nextLine();
} catch(FileNotFoundException e) {
  //do nothing
}
if (str.charAt(0) == 'x') {
   //...
}


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:
Code:
String str;
File f = new File("file.txt");
Scaner inFile = new Scanner(f);
str = inFile.nextLine();

if (str.charAt(0) == 'x') {
   //...
}


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

Although sometimes it is completely pointless. :)


Top
  Profile  
 
 Post subject: Re: Your programming frustrations
PostPosted: Sat Apr 04, 2009 10:11 pm 
Million Club - 5 Plus*
Million Club - 5 Plus*
User avatar

Joined: Sun Sep 12, 2004 6:37 pm
Posts: 4745
Location: In the monkey's litterbox
CrashTECH wrote:
Why on earth would you bother with a try/catch block if you are going to have an empty catch?


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.


Top
  Profile  
 
 Post subject: Re: Your programming frustrations
PostPosted: Sun Apr 05, 2009 5:49 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
smartcat99s wrote:
CrashTECH wrote:
Why on earth would you bother with a try/catch block if you are going to have an empty catch?


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.


Top
  Profile  
 
 Post subject: Re: Your programming frustrations
PostPosted: Tue Apr 21, 2009 8:38 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 985
Location: Earth
CrashTECH wrote:
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):


Code:
public bool IsDateTime(string val) {
  try {
    DateTime d = DateTime.Parse(val);
    return true;
  }catch {
    return false;
  }

}


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).


Top
  Profile  
 
 Post subject:
PostPosted: Tue Apr 21, 2009 8:42 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
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
Code:
public static bool TryParse(
    string s,
    out DateTime result
)


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.


Top
  Profile  
 
 Post subject:
PostPosted: Tue Apr 21, 2009 8:57 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 985
Location: Earth
CrashTECH wrote:
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
Code:
public static bool TryParse(
    string s,
    out DateTime result
)


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
Code:
string _someID = ddlMyControl.SelectedValue;


For me, it's just easier on the eyes (plus DB design is not my forte). :P
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.


Top
  Profile  
 
 Post subject:
PostPosted: Wed Apr 22, 2009 10:52 am 
8086
8086

Joined: Sun Jan 06, 2008 2:40 pm
Posts: 37
Location: Massachusetts
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:

Code:
        private void ClearCookies()
        {
            webBrowser.Document.Cookie = null;
            string cookieDirectory = Environment.GetFolderPath(Environment.SpecialFolder.Cookies);
            string[] cookies = Directory.GetFiles(cookieDirectory);
            for (int i = 0; i < cookies.Length; i++)
            {
                string cookie = cookies[i];
                try
                {
                    File.Delete(cookie);
                }
                catch (Exception ex)
                {

                }
            }
        }


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


Top
  Profile  
 
 Post subject:
PostPosted: Wed Apr 22, 2009 11:21 am 
Java Junkie
Java Junkie
User avatar

Joined: Mon Jun 14, 2004 10:23 am
Posts: 24222
Location: Granite Heaven
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.


Top
  Profile  
 
 Post subject:
PostPosted: Thu Apr 23, 2009 7:09 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 985
Location: Earth
shutout5591 wrote:
Code:
        private void ClearCookies()
        {
            webBrowser.Document.Cookie = null;
            string cookieDirectory = Environment.GetFolderPath(Environment.SpecialFolder.Cookies);
            string[] cookies = Directory.GetFiles(cookieDirectory);
            for (int i = 0; i < cookies.Length; i++)
            {
                string cookie = cookies[i];
                try
                {
                    File.Delete(cookie);
                }
                catch (Exception ex)
                {

                }
            }
        }



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.


Top
  Profile  
 
 Post subject:
PostPosted: Thu Apr 23, 2009 7:13 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 985
Location: Earth
Jipstyle wrote:
As for using try .. catch blocks to escape any looping construct .... ugh.


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:

Code:
if (!someArray.Contains(someIndexToFind)) {
  break; // break out of the loop
}


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.


Top
  Profile  
 
 Post subject:
PostPosted: Thu Apr 23, 2009 7:26 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
I dislike "lazy" stuff. Sometimes, I am lazy though.


Top
  Profile  
 
 Post subject:
PostPosted: Thu Apr 23, 2009 12:32 pm 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 985
Location: Earth
CrashTECH wrote:
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.


Top
  Profile  
 
 Post subject:
PostPosted: Thu Apr 23, 2009 4:05 pm 
Northwood
Northwood
User avatar

Joined: Sun Jul 15, 2007 6:37 pm
Posts: 2261
Location: No. 1 Thread Killer
Jipstyle wrote:
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.


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.


Top
  Profile  
 
 Post subject:
PostPosted: Thu Apr 23, 2009 6:23 pm 
8086
8086

Joined: Sun Jan 06, 2008 2:40 pm
Posts: 37
Location: Massachusetts
DJSPIN80 wrote:
shutout5591 wrote:
Code:
        private void ClearCookies()
        {
            webBrowser.Document.Cookie = null;
            string cookieDirectory = Environment.GetFolderPath(Environment.SpecialFolder.Cookies);
            string[] cookies = Directory.GetFiles(cookieDirectory);
            for (int i = 0; i < cookies.Length; i++)
            {
                string cookie = cookies[i];
                try
                {
                    File.Delete(cookie);
                }
                catch (Exception ex)
                {

                }
            }
        }



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.


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 :P


Top
  Profile  
 
 Post subject:
PostPosted: Fri Apr 24, 2009 3:36 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
Dwood15 wrote:
Jipstyle wrote:
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.


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.


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.

Code:
try {

}
catch (Exception Exp){

}


Top
  Profile  
 
 Post subject:
PostPosted: Fri Apr 24, 2009 3:38 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
shutout5591 wrote:
my method works :P
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 :)


Top
  Profile  
 
 Post subject:
PostPosted: Fri Apr 24, 2009 5:43 am 
Java Junkie
Java Junkie
User avatar

Joined: Mon Jun 14, 2004 10:23 am
Posts: 24222
Location: Granite Heaven
Dwood15 wrote:
Jipstyle wrote:
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.


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.


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? :)


Top
  Profile  
 
 Post subject:
PostPosted: Fri Apr 24, 2009 6:43 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
A good example would show how to handle the exceptions involved. :D


Top
  Profile  
 
 Post subject:
PostPosted: Fri Apr 24, 2009 8:25 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 985
Location: Earth
Dwood15 wrote:
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.


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.


Top
  Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 43 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 8 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group