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!");
Related
Here What I want to do, but do not know if it will work or if there is a better way:
if (condition1){
try {
Block1;
}
} else if (condition2){
try {
Block2;
}
}
catch(ExceptionType1 ex) { process;}
catch(ExceptionType2 ex) { process;}
catch(Exception) {throw;}
So is that the best way this could be done?
This can do what you want.
try {
if (condition1) {
Block1;
} else if (condition2) {
Block2;
}
}
catch(ExceptionType1 ex) { process;}
catch(ExceptionType2 ex) { process;}
catch(Exception) {throw;}
If not, try to put a clear detailed example.
There is no syntax to support exactly, but you might be able to get a similar effect by defining exception classes, and purposely throwing those exceptions in block1 and block2, either through separate try/catches or if/conditonal statements (checking for null, "", etc.)
Here's an example of an exception class behind defined, taken from here
[Serializable()]
public class InvalidDepartmentException : System.Exception
{
public InvalidDepartmentException() : base() { }
public InvalidDepartmentException(string message) : base(message) { }
public InvalidDepartmentException(string message, System.Exception inner) : base(message, inner) { }
// A constructor is needed for serialization when an
// exception propagates from a remoting server to the client.
protected InvalidDepartmentException(System.Runtime.Serialization.SerializationInfo info,
System.Runtime.Serialization.StreamingContext context) : base(info, context) { }
}
In the logic that you want to throw the exceptions in, you just need to define and throw the Exception class you defined. This can be done in a separate catch block, as well
System.ArgumentException argEx = new System.ArgumentException("Index is out of range", "index", ex);
throw argEx;
I'm not sure what you try to achieve with your structure in detail. But I see currently no issue in wrapping the whole statement block into a single try-block #AbdelAzizAbdelLatef mentioned and catch different exception types.
Maybe you can think about, to move your both code blocks (Block1 & Block2) into own functions/methods and perform a specific exception handling there and maybe returning some status code from each new block function. This would be a more clean code approach.
I have Made custom Exception Handler in C# I want to show a readable message for the user if any Exception occurred.
I have tried to specify the Exception pending on it's Hresult Value but I have a problem that I haven't seen, which is showing Hresult value and the specified exception
class UiException : Exception
{
public string Errormessage { get; set; }
public UiException(Exception e)
: base()
{
string exName = e.Source;
int errorNumber = e.HResult;
if (e.HResult == -2146233080)
Errormessage = "Index was outside the bounds of the array.";
}
}
You do not want to use HRESULT for exception identification. HRESULT is mainly there for COM interop and is of little use in .NET. I would recommend the following:
Use the type of the base exception to figure out your custom error message. You stay in .NET and it is more flexible. The main advantage in terms of flexibility is that you can easily cover exceptions derived from other exceptions without having to define a fallback. Also, with an ascast you can easily extract further information from the exception (such as the ParameterName of an ArgumentException).
Make your base exception an inner exception. Inner exceptions are there since the dawn of time .NET and therefore are widely supported, e.g. for logging or debugging. Keeping the source of the error is also good for error analysis and general best practice.
There is absolutely no need for your Errormessage property. There is a Message property, which suits your purpose and (like the inner exception) is widely supported.
So your custom exception should look more like this:
class UIException : Exception
{
public UIException(Exception baseException) :
base(GetErrorMessage(baseException), baseException)
{
}
private static GetErrorMessage(Exception baseException)
{
if (baseException is IndexOutOfRangeException)
{
return "Index was outside the bounds of the array.";
}
else if (exception is InvalidOperationException)
{
//Return exception message
}
//... more else if in the chain
else
{
return baseException.Message;
}
}
}
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'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!).