0

I've a User class like this:

public class User
{
    public string Name { get; set; }
    public string Family { get; set; }
    public string Type { get; set; }
}

And Program.cs file:

public static void Main()
{
    try
    {
        List<User> users = new List<User>();
        users.Add(new User
        {
            Family = "Zamani",
            Name = "Farhad",
            Type = "ADY"
        });
        DoSomething(users);
    }
    catch (Exception ex)
    {
        Console.WriteLine(ex.StackTrace);
    }
}
public static void DoSomething(List<User> users)
{
    var adult = users.Where(a =>  // line 36
                                a.Name.ToUpperInvariant() == "Farhad".ToUpperInvariant()
                             && a.Family.ToUpperInvariant() == "zam".ToUpperInvariant()
                             ).FirstOrDefault();

    (string name, string type) = GetPassengerInfo(GetType(adult.Type), "farhad");//line 41

}
private static (string name, string type) GetPassengerInfo(string v, string d)
{
    return (v, d);
}

static string GetType(string type)
{
    string result = string.Empty;
    switch (type)
    {
        case "ADT":
            result = "Adult";
            break;
    }
    return result;
}

When I run the program in debug mode, Stacktrace of exception display Line:41 and it is ok.

But when I run the project by Release mode I get different line of code in Stacktrace.

In Release mode it show Line:36.

Why?

Farhad Zamani
  • 5,381
  • 2
  • 16
  • 41
  • 2
    That's expected: the point of Debug is to make things like line numbers match what you'd expect. In Release, compiler optimizations mean that the optimized code might not match up properly to the corresponding lines of source code. You just have to live with it. – canton7 Jun 21 '21 at 16:41
  • @canton7 So we should not rely on error log information on the production server? – Farhad Zamani Jun 21 '21 at 16:46
  • You should not rely on specific _line numbers_ in release mode, no. – D Stanley Jun 21 '21 at 16:49
  • @DStanley I debugged the wrong code line for three days and i didn't get anything. – Farhad Zamani Jun 21 '21 at 16:54
  • 1
    This is why default project settings *remove* line number info, it can't be reliable. Nor are stack traces, methods can disappear wholesale. What the optimizer can do is documented [here](https://stackoverflow.com/a/4045073/17034). – Hans Passant Jun 21 '21 at 16:55
  • @DStanley In production server i use **_logger.LogError(ex, ex.ToString())** for error logs and show logs in **kibana** and i get wrong line number. – Farhad Zamani Jun 21 '21 at 17:12
  • 1
    @FarhadZamani You can rely on it, just not on every last detail. The line where the exception occurred is probably somewher *near* the line which was reported, you just have to take the line number with a pinch of salt. Similarly, methods can be removed from the stack trace altogether (due to inlining), so you need to anticipate and account for that – canton7 Jun 22 '21 at 07:40

1 Answers1

0

Why?

Because in release mode, the optimizer can inline functions and do other things that change the actual line number from what you have in source code.

Just outputting the stack trace is probably not helpful (IMHO). What type of exception did you get? What was the error message? What method did it originate from? Those are more helpful for diagnosing problems in my experience. I would change you exception handling to at least Console.WriteLine(ex). That will give you all of that data plus the stack trace.

This link can be helpful.

Farhad Zamani
  • 5,381
  • 2
  • 16
  • 41
D Stanley
  • 149,601
  • 11
  • 178
  • 240