Develop Reference

Try-Catch exception handling in constructor method

I have a seperate class file which contains a constructor method among other methods and I create an instance of this class within a Windows form. I need to do some exception handling within the constructor method, if the required file doesn't exist then catch it with a FileNotFoundException. My only issue is I have no idea how to pass the results of the exception to the Windows form since I can't pass arguments or return any data from the constructor class.

You're making a conceptual mistake. A constructor has a single purpose in life: to prepare a class instance for its busy lifetime. It can therefore have only 2 possible outcomes:
Construction succeeds. The object is usable.
Construction fails because construction was aborted by an exception.
If the file you mention is vital for the object to function, you shouldn't catch the exception and just let it slip outside to the instantiator. It wouldn't make sense in that case to 'return some error' and leave the object half-usable. The event handler in your form should catch the exception and communicate it to the user.
If there is a use case in which a usable object may still be returned, you should implement a static method, something like public static MyClass instantiateConditionally(string filename, out bool somethingHappenedAlongTheWay). This would allow you to return an instance still, and return that something went wrong.

Do you need the object to be successfully constructed even if the exception is thrown?
If you don't then don't handle the exception in the constructor; handle it in the windows form method where you are creating the object.
If you do, then I'd suggest implementing in your object a Boolean property HasErrors that returns true if exception(s) were handled in the constructor. Also implement a method GetErrors() which returns any handled exceptions (conveniently stored in an instance field) or null. This way you can always check in your windows form method if any exception was thrown during the creation of the object and act accordingly.

Do you mean something like this?
public class Form1 : Form
{
...
public void button_Click(...)
{
try
{
var myclass = new MyClass(#"C:\...some file");
...
}
catch (FileNotFoundException)
{
MessageBox.Show("Can't find the file required");
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
}
}
public class MyClass
{
public MyClass(string path)
{
if(string.IsNullOrEmpty(path))
throw new ArgumentNullException();
if(!File.Exists(path))
throw new FileNotFoundException();
...
}
}
Here i create an instance of MyClass when the user clicks on some button.
The class contructor of MyClass throws an exception if no path is given or if the file is not found at the specified path.
I use a try catch to catch any exception thrown and display a messagebox to the user.

Why Do Invoked Method Calls Not Treat All Exceptions as Unhandled Exceptions When on .Net 4.0+?

I've noticed that the "Just My Code"/"Break On Unhandled Exeptions" feature of debugging isn't working when dynamically invoking a method using the .net Framework 4.0 or higher. If I change the project to use the 3.5 framework, it runs just fine.
Given this example Command Line App:
using System;
namespace InvokeFail
{
class Program
{
static void Main(string[] args)
{
HandledExceptions();
}
public static void HandledExceptions()
{
try
{
Fail();
}
catch (NotImplementedException)
{
// handle it amazingly well
}
try
{
InvokeFail();
}
catch (NotImplementedException)
{
// handle it amazingly well
}
}
private static void Fail()
{
throw new NotImplementedException();
}
private static void InvokeFail()
{
try
{
typeof(Program).GetMethod("Fail", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Static)
.Invoke(null, null);
}
catch (System.Reflection.TargetInvocationException ex)
{
throw ex.InnerException;
}
}
}
}
And these VS Debug Options:
Here is a picture of where the debugger stops, and it's call stack:

Apparently there was a purposeful change in the .net framework with the 4.0 version going forward.
See here for a definition of the bug and possible work arounds.
This was just a comment in this question but it makes sense:
When an exception gets thrown in the property, it is unhandled there,
in the property. The MethodInfo invoker (which gets called from
PropertyInfo.GetProperty() translates the real thrown exception into a
TargetInvocationException. So you're not handling the real exception,
you're handling the wrapped exception.

C# re-throwing exception outside of scope

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.

Wrapping logging within an exception object

I currently have this class that another programmer in my team coded:
public static class SoapExecuter
{
private static readonly ILog logger;
public static Exception ExecuterException { get; private set; }
public static bool IsSoapException
{
get
{
if (ExecuterException == null)
return false;
return ExecuterException.GetType() == typeof(SoapException);
}
}
public static bool Execute(Action action)
{
ExecuterException = null;
bool passed = false;
try
{
action();
passed = true;
}
catch (SoapException se)
{
ExecuterException = se;
logger.log(se);
}
catch (Exception ex)
{
ExecuterException = ex;
logger.log(ex);
}
return passed;
}
}
This is not very idiomatic and I would like to change it to something that happens within the try...catch clause.
Is there a way to not violate DRY and still stay within the idioms the language offers?
Of course I can inherit from the SoapException and log it but I'll have to catch a SoapException and create a new exception object that wraps it and then throw it only to be silenced one level above.
Any idea guys?

Sounds like what you really want is not to handle that exception inside Execute at all. The responsibility for handling the exception seems to lie with the code that calls Execute.
Of course you can still catch it, store it in ExecuterException, log it, and then rethrow it using throw; — but the purpose of ExecuterException eludes me. It seems that you only need it for IsSoapException, which in turn is much better written as ExecuterException is SoapException anyway, which even takes care of nullness and subclasses.
I don’t think anyone can be of any further help than this without seeing the code that uses the code you posted. If that code queries ExecuterException only immediately after calling Execute, then you can (and should) probably just change it to a try/catch in that code. If it actually queries ExecuterException elsewhere, then you could consider having that code store the reference instead, but either way, it would mean that the code is pretty entangled spaghetti code and probably requires a major rewrite anyway.
(By the way, just to nitpick, the first of the two catch clauses in your code is completely redundant. If you remove it you get exactly the same behaviour — unless logger.log has a special overload for SoapException, but then you should probably restructure that too.)

How to throw custom exception when exception type was passed by constructor

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!).