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.
Related
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.
I am writing a HttpHandler and as part of my internal design, I throw different exceptions and catch them at the top level in order to determine what status code to set the request to.
I.e.
ArgumentException triggers Bad Request
AuthenticationException triggers Unauthorised
OracleException triggers InternalServerError
etc
The problem I've found is that I was using InvalidOperationException to trigger NotFound, but a bug in my code caused me to realise that, of course, some system exceptions inherit from these base system exceptions, which causes unexpected responses.
I.e. I found that ObjectDisposedException inherits from InvalidOperationException, which means that the response returns a 404 instead of 500.
Is there a way to catch just the base exception?
I found this thread which suggests I could do a filter and rethrow, but that seems hacky.
Would I be better off just creating my own exception types to save all this hassle?
If you only want to pass the HTTP result code (and maybe error message line) to the client, then I recommend you create a single custom exception:
public class MyCustomException : Exception { // Or maybe InvalidOperationException
public int StatusCode {get;set;}
public string Status {get;set;}
}
etc.
As far as I am aware there's no way to catch an exception but not catch inherited exceptions. The problem is that you're considering the base exception to be more specific than the inherited exception, which is the opposite of how they're intended to work (Inherited exceptions should be more specific subsets of their parent, so conceptually if you can handle the parent you should be able to handle the inherited exception).
Your options basically are:
Create your own exception type & only catch this. If your exception falls under the definition of an InvalidOperationException then you can inherit from this. Then you can catch yours specifically.
Catch, inspect, and re-throw if it's not what you're after. This technique I typically try to avoid but is sometimes required if exception types are too generic. e.g.
catch (InvalidOperationException ex) {
if (ex.GetType() != typeof(InvalidOperationException)) throw;
/* Do stuff */
}
It is not possible to only catch base exceptions.
In this case it is best to create a custom exception, rather than use the system's exception types.
public class HttpErrorException : Exception
{
public HttpStatusCode StatusCode { get; private set; }
public HttpErrorException(HttpStatusCode code, string message)
: base(message)
{
this.StatusCode = code;
}
}
throw new HttpErrorException(400, "You sent a bad request!");
If the original intention was to obfuscate the HTTP status codes, and instead use their text names, factory methods can be created.
public class HttpErrorException : Exception
{
public HttpStatusCode StatusCode { get; private set; }
private HttpErrorException(HttpStatusCode code, string message)
: base(message)
{
this.StatusCode = code;
}
public static HttpErrorException BadRequest(string message)
{
return new HttpErrorException(400, message);
}
public static HttpErrorException InternalServerError(string message)
{
return new HttpErrorException(500, message);
}
// etc
}
throw HttpErrorException.BadRequest("You made a bad request!");
I having some classes related like the following domain drawing:
The Requestcontroller is running a loop in a ThreadPool, which on received messages will handle them and call some methods in FooClass, which then should throw exceptions if anything goes wrong.
In example (in some way pseudo-code):
class RequestController
{
private FooClass fooClass;
public RequestController(ref FooClass fooClass)
{
this.fooClass = fooClass;
}
void OnResponseReceived()
{
try
{
this.fooClass.ProcessingRequest("id", "requestType", 13);
}
catch(Exception ex)
{
Debug.Fail(ex.Message);
}
}
}
class FooClass
{
private object myObj;
[...]
public void ProcessingRequest(string id, string type, int count)
{
try
{
myObj.MethodAsync(id, type, RequestFailedCB, myObj);
//This method throws an Exception, that I want to be handled by RequestController class based on the Exception
}
catch(Exception)
{
throw;
}
}
}
So, my problem is that the Async method (MethodAsync in FooClass) will fail, and throw an Exception in FooClass, but it's giving me "Unhandle Exception". What I want is that the Requestcontroller is calling the method of FooClass, and if the async method that has been invoked in the FooClass.ProcessingRequest fails and throws an exception, which my RequestController should react on, and sending a message further on in the system, that there has been an error in the response received.
Would it be an idea to make the ProcessingRequest as and Callback method, or are there any better way to solve this purpose???
EDIT:
#KC-NH without posting pages of complex code, I'll try to get closer to the point.
As commented I forgot to mention that the project i .net 4 target. And the example posted in the FooClass method, is actually calling a .BeginTransfer of the UCMA 4 api, which I want to catch if it fails, and let the RequestController send a message about the failure further on in the system. The .BeginTransfer method returns IAsyncResult, and needs a Callback as one of the parameters.
The exception that the system throws, is inside this CB, but if I try to throw that exception from the Callback, I'm getting "Unhandled Exception", probably cuz the callback doesn't know where to throw that exception??
[.NET 4.5 specific solution]
You should always await async calls. await will rethrow exceptions as expected. This should correct your problem:
class RequestController
{
private FooClass fooClass;
public RequestController(ref FooClass fooClass)
{
this.fooClass = fooClass;
}
public async void OnResponseReceived()
{
try
{
await fooClass.ProcessingRequest();
}
catch (Exception ex)
{
System.Diagnostics.Debug.Fail(ex.Message);
}
}
}
public class FooClass
{
private object myObj;
public async Task ProcessingRequest()
{
await myObj.MethodAsync(id, type, RequestFailedCB, myObj);
}
}
I spoke with one of my colleagues today. He suggested that I used an EventHandler, to raise an event on exception catched in the callback method inside my FooClass. So the solution looks like this:
FooClass RequestFailedCB throws an exception
In RequestFailedCB the exception gets catched, and raising a ErrorEvent on my EventHandler.
The RequestController now gets information, that an event has been raised.
The RequestController will handle the error throw by the event, based on EventArgs and sender object, and can now send that error further on in the system.
Problem solved :) Thanks for all inputs.
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'm using Compact Framework 3.5 / VS2008. I'm getting really odd behavior with TypeLoadException. The following code throws this error. The reason is a problem with the database connection. However for some unknown reason this inner exception is lost and is not contained in the TypeLoadException.
try
{
settingsFromDb = SettingsFromDbManager.Instance;
}
catch (Exception ex)
{
throw ex; // BREAKPOINT HERE
}
If we look at the SettingsFromDbManager class below it can be seen that it is a simple singleton class. The database error is occurring in the Load() method. I haven't included this code in the sample. If I put a breakpoint at the position indicated in the sample below I can see a database error. Unfortunately if I put a breakpoint in the position indicated in the code above then all I get is the TypeLoadException with no inner exception. There is nothing to indicate that a database problem occurred. This is bad :( Does anyone know why this strange behavior could be happening??
Cheers
Mark
public sealed class SettingsFromDbManager
{
static readonly SettingsFromDbManager _instance = new SettingsFromDbManager();
SettingsFromDbManager()
{
try
{
Load();
}
catch (Exception ex)
{
throw ex; // BREAKPOINT HERE
}
}
public static SettingsFromDbManager Instance
{
get
{
return _instance;
}
}
.... more code ...
}
** Update **
Thanks very much for all the great suggestions and help!
Pierre I used the test class you so kindly wrote. Here's the code I called it with. It must be a quirk of the Compact Framework I guess because when I examined the exception it was TypeLoadException with no inner exception :(
try
{
Fail.Test();
}
catch (Exception ex)
{
var x = ex.ToString(); // BREAKPOINT HERE
}
I think VinayC is probably correct about the reason. This is all a bit beyond my knowledge. Not sure what to do now. I don't want to give up my Singleton classes - they are useful. I'm using the "fourth version" Singleton pattern from http://csharpindepth.com/Articles/General/Singleton.aspx. I haven't used them before but seemed like a good idea to share the same instance of some utility classes around the application rather than creating and disposing them numerous times. Performance is a big issue with the Compact Framework.
* Update *
WOO HOO! All I had to do was change the Singleton class as follows. It instantiates the class in the property getter. Now my exceptions bubble to the surface as expected :)
public sealed class SettingsFromDbManager
{
static SettingsFromDbManager _instance = null;
SettingsFromDbManager()
{
try
{
Load();
}
catch (Exception ex)
{
throw new Exception("Error loading settings", ex);
}
}
public static SettingsFromDbManager Instance
{
get
{
if (_instance == null)
_instance = new SettingsFromDbManager();
return _instance;
}
}
.... more code ...
}
From what I know, static constructors may run on a different thread (or more specifically on different call chain) - its a guarantee from runtime that they will be invoked before type is accessed. Exception in the static constructor will mark type as not usable for the app domain. When type is accessed, you will get an TypeInitializationException (as per documentation) but exception occurred within type constructor will not come as inner exception because its not on same call chain - for that matter static constructor might had been executed quite before. Only puzzle out here is TypeLoadException instead of TypeIntializationException as Hans has pointed out.
Edit: Here's the article that explains lazy/eager semantics of type initializers. Your code can be eager implementation (i.e. static constructor may get invoked even before first access to type field)
There is no good reason why the exception raised in the static constructor would not show up in your original call location. However, I don't understand why you do not get the System.TypeInitializationException instead, which should be the exception thrown in case your static constructor fails.
Here is a piece of sample code which throws System.TypeInitializationException with an inner exception set to the "failed" exception:
class Fail
{
static Fail()
{
}
Fail()
{
throw new System.Exception ("failed");
}
static readonly Fail instance = new Fail ();
public static void Test()
{
}
}
I would investigate further to understand why you are getting a TypeLoadException instead, which should occur when an assembly cannot be properly loaded or initialized (TypeLoadException Class in MSDN).