Debugging within try-catch blocks -> where is the flawed piece of code?

Question

3.67/5 (3 votes)

See more:

Hi,

since our programmer has left the team, I am now responsible for the maintenance of our business tool (without being a programmer, really). The tool has historically grown and hence the code is quite messy at times. It consists of huge methods that are encapsulated in cascaded try catch blocks.

I know try catch blocks are best practice, but with huge methods they cause some serious trouble: If the program crashes (while debugging), it won't stop at the flawed piece of code, but rather in the catch block. So, apart from the often not so informative error message, I have no real way of telling which of part of the huge code segment within the try block caused the problem.

The only workaround I've figured out so far is quite tedious: Comment out all the try-catch "surroundings", let the program run and see where it crashes. Without try-catch blocks, it stops right at the erroneous line.

Now, this can't really be it, can it? There must be a way to see which line of code caused the crash even when the try-catch block is active, I am sure of it. I just can't figure out how, and can't google any useful information on that topic, neither.

Any insight is greatly appreciated.

Thank you very much!
- Pesche

Posted 28-Sep-11 8:47am

spitfire_ch

Updated 28-Sep-11 8:48am

v2

Add a Solution

Comments

Sergey Alexandrovich Kryukov 29-Sep-11 18:59pm

By the way: I disagree with the "1" someone voted for this question. I voted 5, as the question is quite reasonable, and Pesche clearly understands and explains the issue.
--SA

spitfire_ch 3-Oct-11 14:02pm

Thank you :)

3 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

OriginalGriff · Accepted Answer · 2011-09-28T08:55:00

Solution 2

Easy peasy.

Look on the Visual Studio menu bar: under the DEBUG menu, you will find "Exceptions". In the dialog that comes up, put a tick in every single check box, both under "thrown" and "User unhandled". (You might want to note which ones are ticked to start with) Press OK.

Now, if you run your app in the debugger (F5 is normally the key) it will stop whenever an exception is thrown, regardless of if it is going to be handled. With a well written program, this will just be the exception you need to find - but there are programs that don't check, and treat exceptions as a flow control method...If it is one of those, then I'm sorry for you!

Posted 28-Sep-11 8:55am

OriginalGriff

Comments

spitfire_ch 28-Sep-11 15:08pm

Great, thank you very much! Just what I was looking for!

OriginalGriff 28-Sep-11 15:32pm

You're welcome!

Sergey Alexandrovich Kryukov 28-Sep-11 23:40pm

My 5.
Just one note: my mentioning flow control method you probably meant to criticize using exceptions for non-error. This problem is not so trivial; and the argument has a long history. Classical books from the time of CLU and Ada explain why exceptions are called exception: exceptional situation which might be something which is not an error -- "reactor overheated", and handling it is a kind of flow control, very unusual, jumping over the stack returns though. In some cases this is exactly that flow control which is really needed. So, I personally support using exception for flow control, but in really rare situations. By the way, I don't see how can it compromise debugging. Over-handling of exceptions and especially blocking their propagation silently -- this is the real evil.
--SA

Sergey Alexandrovich Kryukov · Accepted Answer · 2011-09-28T17:32:00

In addition to the good advice by Griff and Simon, I would advise one more recipe: if your debug execution stops at a breakpoint set in an exception handler block and you cannot see where the exception was thrown, you can examine the property System.Exception.Stack of currently caught exception. If the assembly is compiled in Debug configuration, exception stack will also show file names and line numbers, in addition to the full method names. This is also a good information to put in exception dump: exception stack is just a human-readable string. It's often useful to include System.Exception.InnerException. As this property is also of the type System.Exception you may want to check up all the chain of inner exception, recursively.

—SA

Simon Bang Terkildsen · Accepted Answer · 2011-09-28T08:53:00

Solution 1

You have two options as I see it
1) use #if DEBUG so the try-catch(-finally) is not present when debugging
2) Tell Visual Studio to break when the exception is thrown. You do this by clicking "Exception..." under Debug in the menu.

I prefer 2

Posted 28-Sep-11 8:53am

Simon Bang Terkildsen

Comments

spitfire_ch 28-Sep-11 15:09pm

Awesome, that problem got solved real quickly, thank you very much! :)

Simon Bang Terkildsen 28-Sep-11 15:21pm

You're very welcome

Sergey Alexandrovich Kryukov 28-Sep-11 23:33pm

My 5. I also recommended to check/dump Exception.Stack and InnerException -- please see, I explain why.
--SA

Debugging within try-catch blocks -> where is the flawed piece of code?

3 solutions

Solution 2

Solution 3

Solution 1

Add your solution here

Preview 0

Existing Members

...or Join us