views:

114

answers:

4

If I have a method chain like the following:

        var abc = new ABC();
        abc.method1()
           .method2()
           .methodThrowsException()
           .method3()
           ;

assuming I've defined method1(), method2() and method3() as

    public ABC method1() {
        return this;
    }

and methodThrowsException() as

    public ABC method3() {
        throw new ArgumentException();
    }

When running the code, is it possible to know which specific line of code has thrown the Exception, or will it just consider all the method chaining as just one line? I've done a simple test and it seems it considers them all as just one line but Method Chaining says

Putting methods on separate lines also makes debugging easier as error messages and debugger control is usually on a line by line basis.

Am I missing something, or does that just not apply to C#?

Thanks

Edit: here is what i currently get:

alt text

+1  A: 

The VisualStudio debugger (I assume you're using VS and not Mono, since Mono doesn't have a debugger) knows the actual line that your code is executing, and doesn't roll up all statements to the nearest semicolon, as most C/C++ debuggers tend to do. In the same way, even if you put all statements on the same line, VS is able to show you which method is executing and which one threw the exception.

Edit: Do you actually have an exception being thrown? Then look at the exception stack trace.

JSBangs
Actually Mono has debugger but it's far less power than VS's one
abatishchev
Yeah, I just found that out by looking at their page.
JSBangs
Look at my edit.
devoured elysium
+1  A: 

If you run your sample code you will see that the line reported in the stack trace is actually the line where the exception is thrown and not the line of the method call. The VS debugger will also halt at this line and not on the method call.

Update: As the green error to the left of your screen shot indicates you are not at the top of the call stack. Open the Call Stack window (e.g. via the menu Debug -> Windows -> CAll Stack) and double-click the first line to get to the place where the exception is actually thrown. The first method on the call stack will also be method3().

Note that the quote from Martin Fowler refers to debugging in general, so it might be true for Java IDEs or other integrated debuggers but not for the Visual Studio IDE. Nonetheless you will be able to easily identify the method which caused the problem by looking at the exception's stack trace.

0xA3
+4  A: 

If you look at the stack trace, which is displayed as part of the exception details, you should see the exact location of the exception, no matter how you format the code.

I guess that formatting the code differently would be useful if the debugger allowed you to put a breakpoint on a specific line, but in C#, breakpoints are placed on individual expressions, so this won't really help. You'd probably need to rewrite the code like this to allow placing breakpoints:

var abc = new ABC(); 
var abc1 = abc.method1();
var abc2 = abc1.method2();
// etc...

The same applies to highlighting of the current expression (in your screenshot). However, the exact information about the exception are always available in the stack trace.

Tomas Petricek
+1  A: 

You can see the exact line of code where the exception was generated, but the line of code that called the method that throws exception will be 2 (see numbering below)

         try {

Line 1        var abc = new ABC();
Line 2        abc.method1()
Line 3           .method2()
Line 4           .methodThrowsException()
Line 5           .method3();
Line 6  catch(Exception e)
        {
            StackTrace t = new StackTrace(e, true);
        }

The stacktrace (you can see it either in the exception stacktrace or by creating a StackTrace object) will contain 2 frames:

  • the first will be at the line and file where the method that throws exception is defined

  • the second will be at line 2

anchandra