-2

How to extract that error code without having to depend on casting as seen in the code below? In the screenshot, Number is a property of object InnerException, yet it is not accessible.

try
{
    // db call
}
catch (Exception exc)
{
    // Works
    var q = exc.InnerException as SqlException;
    var ErrorCode = q.Number;
   // Not possible
    var err = exc.InnerException.Number;
}

Why is that not possible and is there an alternative? Also, where to find the documentation for the InnerException Number property?

enter image description here

StriplingWarrior
  • 151,543
  • 27
  • 246
  • 315
usefulBee
  • 9,250
  • 10
  • 51
  • 89
  • It isn't possible without casting. Why aren't you able to cast it? – maembe Aug 17 '17 at 15:42
  • There's no `InnerException Number` property, it's a property of SqlException so if you want to retrieve the number in 1 line: `((SqlException)exc.InnerException).Number` – vc 74 Aug 17 '17 at 15:42
  • @maembe, I am able to cast it as described in the code comment – usefulBee Aug 17 '17 at 15:43
  • @vc74, then how to explain that it is showing in the Locals window under the InnerException object? – usefulBee Aug 17 '17 at 15:44
  • I think he means "why do you not *want* to cast it?" Why are you trying to avoid a cast? – StriplingWarrior Aug 17 '17 at 15:44
  • The `InnerException` property will always return a base `Exception`. You need to cast to the relevant type. Not sure how the debugger gets the values, but it's probably some sort of reflection. – DavidG Aug 17 '17 at 15:44
  • @StriplingWarrior because the Number property is showing without casting under the InnerException object – usefulBee Aug 17 '17 at 15:45
  • @DavidG then we need to know at least how the debugger gets the values. – usefulBee Aug 17 '17 at 15:47
  • Why do you need to know (or care)? – DavidG Aug 17 '17 at 15:47
  • 2
    @usefulBee: When you say it's "showing without casting", you're talking about the way that the Visual Studio debugger is displaying it *at runtime*. At that point in time, Visual Studio knows exactly what type of exception it is, and the values of all its properties. When you're writing and compiling your code, that information is not known. So if you know more than the compiler knows (i.e. you're *assuming* the InnerException is a SqlException), then you need to be explicit about that by adding casting syntax to your code. – StriplingWarrior Aug 17 '17 at 15:51
  • It's not about wanting to know, it's about the question you're asking here. You're not asking how the debugger works at all, and even if you were, that would almost certainly require domain specific knowledge from the people at Microsoft who wrote it, hence it would become off-topic. – DavidG Aug 17 '17 at 15:51
  • 1
    A more on-topic question might be, "how can I get access to all the properties of an exception at runtime, regardless of what type it is." And the simplified answer to that would be to use [reflection](https://learn.microsoft.com/en-us/dotnet/framework/reflection-and-codedom/viewing-type-information). – StriplingWarrior Aug 17 '17 at 15:57

1 Answers1

1

Also, where to find the documentation for the InnerException Number property?

That property is a member of the SqlException class. It is documented here.

Because it is a member of that class, and not the base Exception class, it cannot be accessed directly without some form of casting. (Exception.InnerException is defined as an Exception, not a SqlException.) However, if there's something specific you don't like about the way that you're casting it, there are a few different syntaxes related to casting and type-checking that you may want to leverage. What don't you like about your current approach?

StriplingWarrior
  • 151,543
  • 27
  • 246
  • 315