namespace Rextester
{
public class BaseException : Exception
{
public BaseException() { }
}
public class Program
{
public static void MethodA(BaseException e)
{
Console.WriteLine("BaseException");
}
public static void MethodA(Exception e)
{
Console.WriteLine("Exception");
}
public static void Main(string[] args)
{
try
{
throw new BaseException();
}
catch (Exception e)
{
Console.WriteLine(e.GetType());
MethodA(e);
}
}
}
}
Hello guys i have one question according to the results of the above executed code :
e.GetType() == Rextester.BaseException
MethodA writes to console : Exception
So even though the Type of the exception is the derived class why in the run time is not called the specific overloaded method that has as parameter the BaseException and is called the one with Exception ?
At the following try/catch block:
try
{
throw new BaseException();
}
catch (Exception e)
{
Console.WriteLine(e.GetType());
MethodA(e);
}
an exception is thrown and at the catch the type of the exception is Exception, not BaseException. You basically, throw and a BaseException, but BaseException inherits Exception. So you get into the catch block.
If you wanted to catch the BaseException you should catch this first, since it's more specific.
try
{
throw new BaseException();
}
catch (BaseException e)
{
Console.WriteLine(e.GetType());
MethodA(e);
}
catch (Exception e)
{
Console.WriteLine(e.GetType());
MethodA(e);
}
By the way, it is more clear the name DerivedException than the name BaseException. All exception types in .NET as well as the custom exception types, those that we define for our needs inherit from the Exception class. So all of them are derived classes of the class Exception.
The above can also be found here as below:
Exceptions have the following properties:
Exceptions are types that all ultimately derive from System.Exception.
Once an exception occurs in the try block, the flow of control jumps to the first associated exception handler that is present
anywhere in the call stack. In C#, the catch keyword is used to define
an exception handler.
In addition to the above, you would find helpful the content of this, where it stated that
Multiple catch blocks with different exception filters can be chained together.
The catch blocks are evaluated from top to bottom in your code, but
only one catch block is executed for each exception that is thrown.
The first catch block that specifies the exact type or a base class of
the thrown exception is executed. If no catch block specifies a
matching exception filter, a catch block that does not have a filter
is selected, if one is present in the statement. It is important to
position catch blocks with the most specific (that is, the most
derived) exception types first.
Overloaded methods are bound at compile time.
At compile time, e has type Exception.
That's the reason.
It doesn't matter if the method is static or not. It's compile-time for both.
But after you catch the Exception you can do
dynamic dynEx = e;
MethodA(dynEx);
And you will get the right method called.
The function MethodA is declared as static. Hence any binding to function is at compile time.
Related
In this test code, why does the test fail with an ArgumentNullException, despite that it is handled?
[Test]
public void ExceptionBehaviorTest()
{
// This works. An instance is returned
var testInstance = (TestClass)Activator.CreateInstance(typeof(TestClass), "Hello World");
Assert.NotNull(testInstance);
// This passes. Exception is generated and caught
Assert.Throws<ArgumentNullException>(() => new TestClass(null));
try
{
// This throws ArgumentNullException but the catch handler is not invoked. This fails the test
testInstance = (TestClass)Activator.CreateInstance(typeof(TestClass), (string)null);
Assert.Fail("Should not get here");
}
catch (ArgumentNullException)
{
}
}
private sealed class TestClass
{
public TestClass(string arg)
{
Argument = arg ?? throw new ArgumentNullException(nameof(arg));
}
public string Argument
{
get;
}
}
If I run the code in the debugger, it stops in the TestClass ctor, saying that the exception is not handled. But the calling function is visible in the stack, so the problem is not related to some part being executed on a different thread.
[Background: In my real-world code, I'm iterating over a bunch of classes and testing whether they have a ctor with a specific argument. This is to prevent runtime errors later, as the classes are constructed using dependency injection.]
This is in the documentation
TargetInvocationException
The constructor being called throws an
exception.
So you need to catch TargetInvocationException in this situation, also if you like you can use when though I am not sure it helps with your test much
catch (TargetInvocationException ex) when (ex.InnerException is ArgumentNullException)
{
Console.WriteLine("Caught");
}
I have the following exception that I created for my testing scenarios:
class EvaluationException : Exception
{
public PrettyError ExceptionDetails { get; }
public EvaluationException(PrettyError exceptionDetails)
{
this.ExceptionDetails = exceptionDetails;
}
}
And I'd like to use the following catch block
catch (Exception e)
{
if(e is EvaluationException)
{
e.ExceptionDetails //do stuff;
}
}
However e.ExceptionDetails does not contain a definition for ExceptionDetails. I've tried casting a la (EvaluationException)e and e = e as EvaluationException and I still cannot access the new class attribute that I declared for my custom exception.
How can I do this?
Specific Problem
e is still the wrong type. When you do this:
if(e is EvaluationException)
{
e.ExceptionDetails //do stuff;
}
You're not actually modifying the type of e. It's still an Exception, which indeed doesn't have that property. In order to access that property, you need to interpret e as that type when reading it:
if(e is EvaluationException)
{
(e as EvaluationException).ExceptionDetails //do stuff;
}
or perhaps:
if(e is EvaluationException)
{
var ex = e as EvaluationException;
ex.ExceptionDetails //do stuff;
}
Taking a Step Back
Though, since this is in a catch block, you may make better use of the tooling (and end up with better organized code) to separate your exception handlers by type:
try
{
//...
}
catch (EvaluationException e)
{
// specific handling for this exception type
}
catch (Exception e)
{
// catch-all for non-specific exceptions
}
You can chain as many of those as you like. This allows the runtime to determine which catch block to use, so your code can focus on handling the exception instead of cluttering itself up with trying to determine the exception.
The casting does not work because e is already of type Exception. If you assign to a new variable it would work.
You can also catch specific exception types to make yor life easier like:
catch (EvaluationException evalex)
{
//do stuff
}
catch (Exception ex)
{
// do other stuff
}
my .NET application calls method of object that located out of assembly boundaries. When this method has thrown exception i've catched COMException.
Exception contains special code in ErrorCode field, for example -123.
try
{
// call outside object
}
catch(COMException e)
{
// e.ErrorCode == -123;
}
Is it posible to define exception class that will be thrown instead of COMException?
eg
[ErrorCode of external error = -123]
public class MyException : Exception;
and rewrite above code
try
{
// call outside object
}
catch(MyException e)
{
//...
}
"Is it posible to define exception class that will be thrown instead of COMException?"
No, but you could catch the COMException, wrap it in a custom exception class, and rethrow it.
I am fully aware that what I am about to ask is not good practice... but:
Let's say I have a class containing a function that I want to always return a value, but store any exceptions that might occur for later processing. Something Like:
public Exception _error { get; set; }
public bool IsValid()
{
try
{
//do something here to cause exception
return true;
}
catch (Exception ex)
{
_error = ex;
return false;
}
}
Now that I have stored the exception, is it at all possible to throw the exception from an outside method while maintaining both the original stack trace and exception type?
throw _error; //lose stack trace
throw new Exception("", _error) //lose type
Thanks for looking or answering.
EDIT:
Thanks to some additional points, I realize that the below idea only takes away information and doesn't really add or simplify the situation. Thanks again to everyone.
After pondering Pieter's answer and comments, I'm now wondering if making a wrapper Exception class like the below could be a partial solution. This overrides as much of the exception as possible to make the New exception look like its innerexception, including the stacktrace.. dirty I know, but interesting:
public class ExceptionWrapper : Exception
{
private Exception _innerException;
public ExceptionWrapper(Exception ex) : base("", ex)
{
_innerException = ex;
this.Source = ex.Source;
this.HelpLink = ex.HelpLink;
}
public override string StackTrace
{
get
{
return _innerException.StackTrace;
}
}
public override System.Collections.IDictionary Data
{
get
{
return _innerException.Data;
}
}
public override string Message
{
get
{
return _innerException.Message;
}
}
public new Exception InnerException
{
get
{
return _innerException.InnerException;
}
}
}
No, this is not possible.
However, you normally solve this is by wrapping the exception in a new exception:
throw new MyException("Wrapper", _error);
This does maintain the stack trace of _error, but you do get a new exception. Your solution in your second example is the correct way of handling these cases.
Consider using reflection to create a wrapper exception of the correct type (Activator.CreateInstance) and calling the constructor that will accept the inner exception you have stored.
For example:
[Test]
public void test()
{
Exception ex = new ArgumentNullException();
Exception wrapped = (Exception)Activator.
CreateInstance(ex.GetType(), "wrapped", ex);
Type expectedType = typeof(ArgumentNullException);
Assert.IsInstanceOf(expectedType, wrapped, "Is ArgumentNullException.");
Assert.AreEqual(ex, wrapped.InnerException, "Exception is wrapped.");
}
Update
In order to mitigate the constructor issue, you could consider using the default constructor (should be there for an exception that follows design guidelines, but not mandatory) and then patching up the new instance by setting its fields via reflection.
I agree the approach is highly "meh" it's more an exploration of an idea. I wouldn't recommend it.
The exception design guidelines require a default constructor, so this sort of behaviour may go on in the framework somewhere anyway. Perhaps for some sort of icky serialization\deserialization of exceptions across some sort of communications boundary?
It seems that .net-4.5 added a new API for capturing stack/info about exceptions and rethrowing them in different contexts. This is called ExceptionDispatchInfo. It is useful if you find yourself needing more control over running tasks indirectly, like if you do manual thread management for jobs or Task does not exactly fit your needs. In your example, it should look like this:
public ExceptionDispatchInfo _error { get; private set; }
public bool IsValid()
{
try
{
//do something here to cause exception
return true;
}
catch (Exception ex)
{
_error = ExceptionDispatchInfo.Capture(ex);
return false;
}
}
/// <summary>Throw underlying exception if invalid.</summary>
public void AssertWasValid() => _error?.Throw();
Now, it doesn’t preserve the original caller. The displayed stack trace shows the calls from the original try block into the code in there, a statement breaking the original and new parts of the stack, and then the calls into ExceptionDispatchInfo.Throw() itself as the new part of the shown stack. This seems similar to how traces with async code look. If you care about the original caller, seems this won’t work. But if you care about getting the line/method that threw the exception, this should be sufficient.
I've created class that takes Exception type in constructor
private readonly Exception _exception;
public StringToObject(Exception exception)
{
_exception = exception;
}
i wanted to throw exception
throw new _exception("");
but i got error:
'._exception' is a 'field' but is used like a 'type'
is any possible ways to throw it?
This is not a good practice at all. Doing so will cause you to lose your stack trace related information. Please consider reading this section of Eric Lippert's blog:
Too Much Reuse
When you write
throw new Exception();
you instantiate this new exception. But then, since your private member _exception is already instantiated, you don't need to re-instantiate it, that is instantiating an instance, which doesn't make sense. Instead, use the following:
throw _exception;
This will do it.
To rethrow an existing exception like that use
throw _exception;
However, that will modify the call stack in the exception instance, so you will lose the original source of the exception. If you want to avoid that, you can throw a new exception with the instance as an inner exception.
I'm actually very confused about why you want to do this? Are you trying to create a custom exception to provide more information? If so, then you want to use this pattern.
First define a custom exception class that derives from Exception:
public class MyCustomException : Exception // Or you could derive from ApplicationException
{
public MyCustomException(string msg, Exception innerException)
: base(msg, innerException)
{
}
}
You could also define additional parameters in your custom exception constructor to contain even more information if you wish. Then, in your application code...
public void SomeMethod()
{
try
{
// Some code that might throw an exception
}
catch (Exception ex)
{
throw new MyCustomException("Additional error information", ex);
}
}
You'll want to be sure to keep track of the inner exception, because that will have the most useful call stack information about what caused the exception in the first place.
throw _exception;
This example should work. I´ve included all the classes involved in the example.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace ConsoleApplication1
{
public class MyException : Exception
{
public MyException(string message) : base(message)
{}
//...
}
public class MyClass
{
private Exception exception;
public MyClass(Exception e)
{
this.exception = e;
}
public void ThrowMyException()
{
throw exception;
}
}
class Program
{
static void Main(string[] args)
{
MyException myExceptionInstance = new MyException("A custom message");
MyClass myClassInstance = new MyClass(myExceptionInstance);
myClassInstance.ThrowMyException();
}
}
}
I suspect that what you're really looking for is to throw a new exception of your suggested type, in which case passing in a "Type" parameter (or even using a generic) would be the way forward.
However, I can't imagine a situation where this is a sensible design choice, so I'd have to urge you to reconsider (and perhaps post more of your requirements so that someone can suggest a better alternative!).