We Keep Coding

WebJob and ExceptionFilterAttribute

I use ExceptionFilterAttribute for my web api application to catch different unhandled exceptions, i.e.:
public class InvalidDriverExceptionAttribute : ExceptionFilterAttribute
{
public override void OnException(HttpActionExecutedContext actionExecutedContext)
{
if (actionExecutedContext.Exception != null)
{
if (actionExecutedContext.Exception is Domain.InvalidDriverException)
{
var resp = actionExecutedContext.Request.CreateErrorResponse(HttpStatusCode.NotFound, "User is not a driver");
actionExecutedContext.Response = resp;
}
}
//base.OnException(actionExecutedContext);
}
}
but I want to have similar engine for my web job. Is it possible?

but I want to have similar engine for my web job. Is it possible?
Yes. But because web jobs are continuous or schedule, there are some differences in how they are implemented. You could use ErrorTrigger to achieve your goal. An error trigger that allows you to annotate functions to be automatically called by the runtime when errors occur. It could monitor errors in web job when it is executed.My Demo result like this:filter null exception. For more details, you could refer to this article.
When developing jobs with Azure WebJob, it's a good practice to implement error monitoring in case something goes wrong when a job is executed.
The WebJobs ErrorTrigger extension, part of the Core extensions, will help us achieve that.

I have created derived class from FunctionExceptionFilterAttribute
public class ErrorHandlerAttribute : FunctionExceptionFilterAttribute
{
public override async Task OnExceptionAsync(FunctionExceptionContext exceptionContext, CancellationToken cancellationToken)
{
string body = $"ErrorHandler called. Function '{exceptionContext.FunctionName}': {exceptionContext.FunctionInstanceId} failed. ";
CombineErrorWithAllInnerExceptions(exceptionContext.Exception, ref body);
string[] emailList = System.Configuration.ConfigurationManager.AppSettings["SendErrorEmails"].Split(';');
await SendEmail.SendErrorNotificationAsync("WebJob - Common Driver Error", body);
}
private void CombineErrorWithAllInnerExceptions(Exception ex, ref string error)
{
error += $"ExceptionMessage: '{ex.Message}'.";
if (ex is Domain.BadStatusCodeException)
{
error += $"Status code: {((Domain.BadStatusCodeException)ex).StatusCode}";
}
if (ex.InnerException != null)
{
error += $"InnerEx: ";
CombineErrorWithAllInnerExceptions(ex.InnerException, ref error);
}
}
}
and then use it for method:
[NoAutomaticTrigger]
[ErrorHandler]
public async Task GetDriversAsync(TextWriter logger)
{
when exception occurs it call this code and send notification email to me

How to Implement Server Side Error Handling for Web Socket

I want to implement all types error Handling for web socket implementation at server side.
My Server Side Code
public class WebSocketManager : WebSocketHandler
{
public override void OnOpen()
{
// Do when Connection Is Open
}
public override void OnClose()
{
// Close Connection
}
public override void OnMessage(string message)
{
// When Any Message Sent to Client
}
}

You can add exception handling using try catch blocks and log the errors to a log file. Like this:
http://www.codeproject.com/Articles/2344/Create-Simple-Error-Log-Files-using-ASP-NET-and-C
Or you can log them to the event viewer if you want.

Web API 2 - Global Exception Handler not working with TaskCancellation

Code to demonstrate the problem:
Assume Test Thing is an real implementation, such as DB invocation.
The documentation for Web API states that unhanded exceptions will be caught in a global handler allowing you to process them.
If I replace MyErrorHandler with an ExceptionFilter this does indeed work, except the code base I'm working with uses handlers because the error logic is a cross cutting concern and will be the same regardless of where the error came from.
If the type of exception thrown is not a TaskCancelledException this invokes the handler as expected.
I've tried the latest version of Web API too (5.2.3).
The only work around is to add a try/catch block around everywhere that can throw this type of exception, needless to say this is painful and something I wish to avoid hence the use of the handler.
I hate to call this a bug given this is not my code, but after hours of attempts it's starting to feel that way.
using System;
using System.Net;
using System.Threading;
using System.Threading.Tasks;
using System.Web.Http;
using System.Web.Http.ExceptionHandling;
namespace WebApplication3.Controllers
{
public class TestController : ApiController
{
public async Task<string> Get()
{
var cancellationTokenSource = new CancellationTokenSource(TimeSpan.FromSeconds(1));
return await new TestThing().ExecuteAsync(cancellationTokenSource.Token);
}
}
public class MyErrorHandler : ExceptionHandler
{
public override Task HandleAsync(ExceptionHandlerContext context, CancellationToken cancellationToken)
{
throw new HttpResponseException(HttpStatusCode.InternalServerError);
}
}
public class TestThing
{
public async Task<string> ExecuteAsync(CancellationToken cancellationToken)
{
// Remove this to see the problem, I don't want to add these
// try/catch statements all over the codebase.
try
{
await Task.Delay(TimeSpan.FromMinutes(1), cancellationToken);
}
catch (Exception ex)
{
throw new Exception("Failure...");
}
return await Task.FromResult("Testing...");
}
}
}

Given the lack of suggestions or answers I went with a custom message handler.
public class AsyncFixHandler : DelegatingHandler
{
protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
{
try
{
return await base.SendAsync(request, cancellationToken);
}
catch (TaskCanceledException)
{
// TODO: Log the issue here
return new HttpResponseMessage(HttpStatusCode.InternalServerError);
}
}
}
This isn't ideal, but the try/catch is in one place. I'm using this successfully as the solution until something better comes along.

It seems like it's and old bug, and there are some people reporting issues still. I suggest you to create an issue in ASP.NET Github repo and use your workaround or another one for the moment.

code duplication in try catch block

Is there a better way to catch exceptions? I seem to be duplicating a lot of code. Basically in every controller I have a catch statement which does this:
try
{
Do something that might throw exceptions.
}
catch (exception ex)
{
Open database connection
Save exception details.
If connection cannot be made to the database save exception in a text file.
}
I have 4 controllers and around 5-6 actions methods in each controller which is a lot of code duplication. How can I trim down on the amount of line in the try catch statement above?

You could make use of Extension methods here.
Create an extension method in a new class.
public static class ExtensionMethods
{
public static void Log(this Exception obj)
{
// log your Exception here.
}
}
And use it like:
try
{
}
catch (Exception obj)
{
obj.Log();
}

You don't need to put try/catch blocks on every method. That's tedious and painful! Instead you can use the Application_Error event of Global.asax for logging the exceptions. The code below is the sample implementation which can be used to catch exceptions that occur in your web application.
protected void Application_Error(object sender, EventArgs e)
{
var error = Server.GetLastError();
if (!string.IsNullOrWhiteSpace(error.Message))
{
//do whatever you want if exception occurs
Context.ClearError();
}
}
I would like also to stress that "Handled exception" especially trying to put try/catch blocks on most methods is one of the "Top 3 silent performance killers for IIS / ASP.NET apps" as explained in this blog http://mvolo.com/fix-the-3-high-cpu-performance-problems-for-iis-aspnet-apps/

What you are trying to do is called a cross-cutting concern. You are trying to log any error that happens anywhere in your code.
In ASP.NET MVC cross-cutting concerns can be achieved by using Filters. Filters are attributes that can be applied globally, to a controller or to a method. They run before an action method executes or after it.
You have several types of filters:
Authorization filters, they run to check if the user is allowed to access a resource.
Action filters, these run before and after an action method executes.
Result filters, these can be used to change the result of an action method (for example, add some extra HTMl to the output)
Exception filters run whenever an exception is thrown.
In your case, you are looking for exception filters. Those filters only run when an exception happens in in an action method. You could apply the filter globally so it will automatically run for all exceptions in any controller. You can also use it specifically on certain controllers or methods.
Here in the MSDN documentation you can find how to implement your own filters.

Personally, since I greatly dislike try/catch blocks, I use a static Try class that contains methods that wrap actions in reusable try/catch blocks. Ex:
public static class Try {
bool TryAction(Action pAction) {
try {
pAction();
return true;
} catch (Exception exception) {
PostException(exception);
return false;
}
}
bool TryQuietly(Action pAction) {
try {
pAction();
return true;
} catch (Exception exception) {
PostExceptionQuietly(exception);
return false;
}
}
bool TrySilently(Action pAction) {
try {
pAction();
return true;
} catch { return false; }
}
// etc... (lots of possibilities depending on your needs)
}

I have used a special class in my applications that is called ExceptionHandler, in the class that is static I have some methods to handle application's exceptions. It gives me an opportunity to centralize exception handling.
public static class ExceptionHandler
{
public static void Handle(Exception ex, bool rethrow = false) {...}
....
}
In the method you can log the exception, rethrow it, replace it with another kind of exception, etc.
I use it in a try/catch like this
try
{
//Do something that might throw exceptions.
}
catch (exception ex)
{
ExceptionHandler.Handle(ex);
}
As Wouter de Kort has rightly stated in his answer, it is cross-cutting concern, so I've put the class in my Application Layer and have used it as a Service. If you defined the class as an interface you would be able to have different implementations of it in different scenarios.

Also you can use Singleton pattern:
sealed class Logger
{
public static readonly Logger Instance = new Logger();
some overloaded methods to log difference type of objects like exceptions
public void Log(Exception ex) {}
...
}
And
Try
{
}
Catch(Exception ex)
{
Logger.Instance.Log(ex);
}
Edit
Some peoples don't like Singleton for reasonable grounds.instead of singleton we can use some DI:
class Controller
{
private ILogger logger;
public Controller(ILogger logger)
{
this.logger = logger;
}
}
And use some DI library that will inject one instance of ILogger into your controllers.

I like the answers suggesting general solutions, however I would like to point out another one which works for MVC.
If you have a common controller base (wich you should anyways, it's a Best Practice IMO). You can simply override the OnException method:
public class MyControllerBase : Controller
{
protected override void OnException(ExceptionContext filterContext)
{
DoSomeSmartStuffWithException(filterContext.Exception);
base.OnException(filterContext);
}
}
Then simply inherit your normal controllers from your common base instead of Controller
public class MyNormalController : MyControllerBase
{
...
If you like this you can check out the Controller class for other handy virtual methods, it has many.

In ASP .NET MVC you can implement your own HandleErrorAttribute to catch all the exceptions that occur in all controllers:
public class CustomHandleErrorAttribute : HandleErrorAttribute
{
public override void OnException(ExceptionContext filterContext)
{
var ex = filterContext.Exception;
// Open database connection
// Save exception details.
// If connection cannot be made to the database save exception in a text file.
}
}
Then register this filter:
public class FilterConfig
{
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new CustomHandleErrorAttribute());
}
}
And of-course call the register method on application start-up:
public class MvcApplication : HttpApplication
{
protected override void OnApplicationStarted()
{
// ...
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
// ...
}
}
Wouter de Kort has already explained the concept behind this in his answer.

WCF Error Handler Exception Logging

I use IErrorHandler in my project for handle exceptions.
But how can i log incoming method parameter with exception.
I want to get Request parameter for logging.
Sample Method:
public Response GetData(Request request) {
return new Response();
}

You could get the request message like this:
Message requestMessage = OperationContext.Current.RequestContext.RequestMessage;
What I do usually is to log the entire request XML.

You don't have such information in IErrorHandler - you can only parse raw message in ProvideFault method.
You can try to use another approach - implement custom IOperationInvoker and in Invoke method do something like:
// Just synchronous implementation - for asynchronous handle InvokeBegin and InvokeEnd
public object Invoke(object instance, object[] inputs, out object[] outputs)
{
try
{
// Run common invoker - you will create new Invoker as decorator for existing one.
return innerInvoker.Invoke(instance, inputs, outputs);
}
catch(Exception e)
{
// Handle error here
}
}
Operation invoker is responsible for selection correct operation in service and ivoke it. It is just idea - I haven't tested it.

Two ways:
The native WCF logger will capture all requests & responses when set to verbose however, these files tend to get real big, real quick.
Use log4net (search google to download)
private static readonly ILog log = LogManager.GetLogger(typeof(MyClass));
public class MyClass
{
...
public Foo DoSomething(string arg)
{
try
{
//do something
}
catch(Exception e)
{
log.error(string.format("{0} Arguements: {1}", e.Tostring(), arg);
}
}
}