3

I need to read different types of .txt files and for that I first read the first few lines where is the heading situated. With that information I'm able to select the way of reading it. The problem is that if only one record are in different format (say I substring(0,45) and there are only 40 characters) my application crashes. I want to avoid this, but I can't check every possibility. I've read that you should avoid use too much try/catch, and I'm only using it when I don't know where the error could come from.

My question is: it is bad to use try/catch in a loop (30k - 40k times)?

If it's not, how can I use it properly? I don't understand completely the purpose of exceptions. Are they only for debugging? If not, what differences are between throw new exception and MessageBox.Show("Error").

If I don't notify about the error and just skip it could I write something like this:

try
{
//problematic code
}
catch
{
//nothing
//continue;
}
Sturm
  • 3,968
  • 10
  • 48
  • 78
  • Why do you want to avoid this? The file is bad, not something you want to ignore. If you catch and swallow the exception then you have only accomplished writing a program that ignores bad data so very likely creates bad data as well. Without *any* way for the user to figure out where the problem might be. – Hans Passant Aug 02 '13 at 17:51
  • Yes, you're right. I was thinking of other situation for using that snippet. Thanks for the suggestion. PD. what can I do if the user selects a corrupted file and I throw 30k exceptions? – Sturm Aug 02 '13 at 18:08

3 Answers3

3

but I can't check every possibility

Yes, you can! This is how it is normally done. When engineering a complex function you want to think about every case. Every case not thought about is a potential bug.

And your try-catches are hiding the bugs you did not think about. You want to have exceptions bubble up so you notice them and fix the underlying problem.

Strictly adhere to the convention that all nullref and indexoutofbounds exceptions are always bugs. This saves you time in the end.

usr
  • 168,620
  • 35
  • 240
  • 369
  • One of the signs of a good engineer is one that doesn't introduce superfluous cases. For example, if your do not require a nullable value type, use only a value type and you remove unnecessary complexity and there are less scenarios to validate. Engineers often muse and debate over the correct amount of abstraction. The best way to know if further abstraction is the right choice is with 2 questions: 1. Does it satisfy requirements? 2. Does further abstraction increase the number of cases that must be handled? – N-ate Dec 02 '14 at 20:30
3

it is bad to use try/catch in a loop (30k - 40k times)?

Only if you expect a significant amount of exceptions. If exceptions are not thrown, there is very little in performance overhead.

Are they only for debugging?

No, but mostly used to find bugs during runtime (mostly one logs exceptions so you can see where/why the program crashed). You cannot anticipate all eventualities, so having a log in place that you can consult once it does crash is very helpful.

They also allow for recovery (if you know what caused the exception and know how to handle it). One example of this is database transaction deadlocks - when two threads compete for the same database resources, one will be chosen to terminate (the deadlock victim) - this can only be caught with an exception and handled by retrying the transaction.

The following is hugely problematic:

catch
{
//nothing
}

Why? Because you end up ignoring exceptions that you have not anticipated - you throw them away and when you program does end up crashing or having strange bugs, you will have no idea why.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • I forgot to mention that in that catch I would exit the loop. As I store the read lists at the end I will get an empty file and that I've ensured that won't give problems. Isn't this correct? – Sturm Aug 02 '13 at 17:46
  • @Sturm - I don't know. Really depends on the logic required by your application. – Oded Aug 02 '13 at 17:47
2

From a performance standpoint, there is a tiny performance hit when having code run in a try-catch block versus not. Check out Do try/catch blocks hurt performance when exceptions are not thrown? for empirical evidence of the difference.

What are the differences between throw new exception and MessageBox.Show("Error")?

For starters, an exception is an object that can hold information and being extended to creat your own custom exceptions, while MessageBox.Show() just uses text to display to the user. In short, one is an object while another is a mechanism to display information to the user. They should not be viewed as competing choices, but rather as complements.

Finally, catch { //nothing } is a horrible idea, it is the equivalent of putting your head in the sand to avoid hearing bad news. NEVER EVER do this!

Community
  • 1
  • 1
Karl Anderson
  • 34,606
  • 12
  • 65
  • 80
  • 1
    By tiny, you mean *virtually insignificant*. According to the other answer, they measured the overhead at less than 15% of the cost of a single call to `Math.Sin` (which is not as fast as integer multiplication, but is certainly much faster than a call to `Substring` like the OP here is using). In the OP's usage, the overhead would probably not even be measurable, let alone noticeable to a user. – Sam Harwell Aug 02 '13 at 17:47
  • So like reflection don't put it in high traffic areas, but unlike reflection in high traffic areas it isn't going to destroy your performance. :) – N-ate Dec 02 '14 at 20:33