Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free.
I have a global ExceptionFilter in my Mvc\WebApi application registered as:
public virtual void RegisterHttpFilters(HttpConfiguration config)
config.Filters.Add(new MyExceptionFilter(_exceptionHandler));
where MyExceptionFilter is:
public class MyExceptionFilter : ExceptionFilterAttribute
private readonly IMyExceptionHandler m_exceptionH
public MyExceptionFilter(IMyExceptionHandler exceptionHandler)
m_exceptionHandler = exceptionH
public override void OnException(HttpActionExecutedContext context)
Exception ex = context.E
if (ex != null)
object response =
HttpStatusCode statusCode = m_exceptionHandler != null
? m_exceptionHandler.HandleException(ex, out response)
: HttpStatusCode.InternalServerE
context.Response = context.Request.CreateResponse(statusCode, response ?? ex);
base.OnException(context);
This filter returns all exceptions as json-objects and allows some IMyExceptionHandler-implementation to customize the object being returned.
All this works well. Till I have an exception in some of my message handlers:
public class FooMessageHandler : DelegatingHandler
private readonly Func&IBar& _barF
public FooMessageHandler(Func&IBar& barFactory)
_barFactory = varF
protected override Task&HttpResponseMessage& SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
request.Properties["MY_BAR"] = _barFactory();
return base.SendAsync(request, cancellationToken);
As you can see this handler creates some component and put it into the current http request message.
When an exception happens in FuncOfIBar then I get the Yellow Screen of Death. My ExceptionFilter isn't called.
I tried to specifically catch the exception in the message handler and return HttpResponseException but it doesn't change anything - still getting YSOD:
public class XApplicationInitializerMessageHandler : DelegatingHandler
private readonly Func&IXCoreApplication& _appF
private readonly IXExceptionHandler m_exceptionH
public XApplicationInitializerMessageHandler(Func&IXCoreApplication& appFactory, IXExceptionHandler exceptionHandler)
ArgumentValidator.EnsureArgumentNotNull(appFactory, "appFactory");
_appFactory = appF
m_exceptionHandler = exceptionH
protected override Task&HttpResponseMessage& SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
request.SetApplication(_appFactory());
catch (Exception ex)
object resultObject =
HttpStatusCode statusCode = m_exceptionHandler != null
? m_exceptionHandler.HandleException(ex, out resultObject)
: HttpStatusCode.InternalServerE
HttpResponseMessage responseMessage = request.CreateResponse(statusCode, resultObject ?? ex);
throw new HttpResponseException(responseMessage);
return base.SendAsync(request, cancellationToken);
I want behavior of my app to be same regardless where an exception happens: in a ApiController or a message handler.
How to do this?
I know about Application_Error but I'd like to keep HttpApplication customization untouchable.
3,32852859
OK, instead of throwing HttpResponseException I should jsut return HttpResponseMessage:
protected override Task&HttpResponseMessage& SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
request.SetApplication(_appFactory());
catch (Exception ex)
object resultObject =
HttpStatusCode statusCode = m_exceptionHandler != null
? m_exceptionHandler.HandleException(ex, out resultObject)
: HttpStatusCode.InternalServerE
HttpResponseMessage responseMessage = request.CreateResponse(statusCode, resultObject ?? ex);
return Task&HttpResponseMessage&.Factory.StartNew(() =& responseMessage);
return base.SendAsync(request, cancellationToken);
3,32852859
I had the same issue with global exception filters not running. The solution was that Web API exception filters must be configured in a different global collection than ASP.NET MVC exception filters.
So to configure ASP.NET MVC error handling you would run:
System.Web.Mvc.GlobalFilters.Filters.Add(new MyMvcExceptionFilter());
But for Web API error handling you must run:
System.Web.Http.GlobalConfiguration.Configuration.Filters.Add(new MyWebApiExceptionFilter());
From my limited experience with Web API this type of situation is typical: superficially the patterns used will be very similar to ASP.NET MVC and so instantly familiar. This gives the illusion that writing one piece of code will have an effect on both frameworks, but actually their implementations underneath it all are largely or completely separate and you'll need to write two versions of the code that are very similar to make it all work.
Excellent reference on Web API exception handling:
What I have done with succes is using an attribute-based approach. You place an custom attribute on each of the actions that should used exception handling:
[ExceptionHandling]
public IEnumerable&string& Get()
Your custom exception handling attribute is implemented like this:
public class ExceptionHandlingAttribute : ExceptionFilterAttribute
public override void OnException(HttpActionExecutedContext context)
As you can see you, the custom attribute is inherited from ExceptionFilterAttribute. You then just override the OnException method. What you then can do is look at the type of the exception and handle it according to business rules or what ever fits your needs. In some cases you might just swallow the exception on the server. If you want to notify the client, you can throw an HttpResponseException, which can hold all relevant information, such as message, call stack, inner exception, etc.
For more inspiration take a look at this great blog post:
Your Answer
Sign up or
Sign up using Google
Sign up using Facebook
Sign up using Stack Exchange
Post as a guest
Post as a guest
By posting your answer, you agree to the
Not the answer you're looking for?
Browse other questions tagged
Top questions and answers
Important announcements
Unanswered questions
By subscribing, you agree to the
Stack Overflow works best with JavaScript enabledClass: Exception (Ruby 1.9.3)
Quicksearch
Descendants of class Exception are used to communicate between
raise methods and rescue statements in
begin/end blocks. Exception objects carry
information about the exception—its type (the exception’s class name), an
optional descriptive string, and optional traceback information. Programs
may subclass Exception, or more typically
StandardError to provide custom classes and add additional
information.
With no argument, or if the argument is the same as the receiver, return
the receiver. Otherwise, create a new exception object of the same class as
the receiver, but with a message equal to string.to_str.
Construct a new
object, optionally
passing in a message.
static VALUE
exc_initialize(int argc, VALUE *argv, VALUE exc)
rb_scan_args(argc, argv, &01&, &arg);
rb_iv_set(exc, &mesg&, arg);
rb_iv_set(exc, &bt&, Qnil);
Equality—If obj is not an Exception, returns
false. Otherwise, returns true if exc
and obj share same class, messages, and backtrace.
static VALUE
exc_equal(VALUE exc, VALUE obj)
VALUE mesg,
if (exc == obj) return Q
CONST_ID(id_mesg, &mesg&);
if (rb_obj_class(exc) != rb_obj_class(obj)) {
ID id_message, id_
CONST_ID(id_message, &message&);
CONST_ID(id_backtrace, &backtrace&);
mesg = rb_check_funcall(obj, id_message, 0, 0);
if (mesg == Qundef) return Q
backtrace = rb_check_funcall(obj, id_backtrace, 0, 0);
if (backtrace == Qundef) return Q
mesg = rb_attr_get(obj, id_mesg);
backtrace = exc_backtrace(obj);
if (!rb_equal(rb_attr_get(exc, id_mesg), mesg))
if (!rb_equal(exc_backtrace(exc), backtrace))
Returns any backtrace associated with the exception. The backtrace is an
array of strings, each containing either “filename:lineNo: in `method”‘ or
“filename:lineNo.”
raise &boom&
rescue =& detail
print detail.backtrace.join(&\n&)
prog.rb:2:in `a'
prog.rb:6:in `b'
prog.rb:10
static VALUE
exc_backtrace(VALUE exc)
CONST_ID(bt, &bt&);
return rb_attr_get(exc, bt);
With no argument, or if the argument is the same as the receiver, return
the receiver. Otherwise, create a new exception object of the same class as
the receiver, but with a message equal to string.to_str.
static VALUE
exc_exception(int argc, VALUE *argv, VALUE self)
if (argc == 0)
if (argc == 1 && self == argv[0])
exc = rb_obj_clone(self);
exc_initialize(argc, argv, exc);
Return this exception’s class name an message
static VALUE
exc_inspect(VALUE exc)
VALUE str,
klass = CLASS_OF(exc);
exc = rb_obj_as_string(exc);
if (RSTRING_LEN(exc) == 0) {
return rb_str_dup(rb_class_name(klass));
str = rb_str_buf_new2(&#&&);
klass = rb_class_name(klass);
rb_str_buf_append(str, klass);
rb_str_buf_cat(str, &: &, 2);
rb_str_buf_append(str, exc);
rb_str_buf_cat(str, &&&, 1);
Returns the result of invoking exception.to_s. Normally this
returns the exception’s message or name. By supplying a to_str method,
exceptions are agreeing to be used where Strings are expected.
static VALUE
exc_message(VALUE exc)
return rb_funcall(exc, rb_intern(&to_s&), 0, 0);
Sets the backtrace information associated with exc. The argument
must be an array of String objects in the format described in
Exception#backtrace.
static VALUE
exc_set_backtrace(VALUE exc, VALUE bt)
return rb_iv_set(exc, &bt&, rb_check_backtrace(bt));
Returns exception’s message (or the name of the exception if no message is
static VALUE
exc_to_s(VALUE exc)
VALUE mesg = rb_attr_get(exc, rb_intern(&mesg&));
VALUE r = Q
if (NIL_P(mesg)) return rb_class_name(CLASS_OF(exc));
r = rb_String(mesg);
Please enable JavaScript to view theStack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free.
I'm pretty sure I already know the answer, but I'm still curious what the opinion is on handling an error within a Try,Catch,Finally block -- but when you're repeating yourself.
BTW - I'm not talking about User Input - but using that for an example because it is clear and short
Consider this bit of code...
if (success) {
return someSuccessM
logError("User input not correct format");
return someErrorM // repeats itself
catch (Exception ex) {
logError(ex.Message);
return someErrorM // repeats itself
Say we have a function, that if it fails we want to return an error message because the exception is irrelevant -- our function did not succeed and the user doesn't need any additional detail.
I've always held the belief that if you can handle the error, avoid the exception -- since it isn't exceptional anymore, but I wondered the opinion about avoiding repeating yourself as well... You could do the following to avoid repeating yourself...
if (success) {
return someSuccessM
throw new Exception("User input not correct format");
catch (Exception ex) {
logError(ex.Message);
return someErrorM
This isn't the best example, but I was going for brevity to make the point of repeating code.
Exceptions are known to incur a performance penalty, but what are the thoughts about a situation like this?
15.3k194367
I question the separation of concerns here. Unless this function is part of the UI, it should not concern itself with error messages. It should be throwing exceptions instead. The caller of this method, if it's part of the UI, might want to produce an error message for display. If the caller were a web service, then it would want to produce a SOAP Fault, which might not use the same message (if it used any message at all).
I would also strongly suggest you log ex.ToString() and not ex.Message.
130k16148297
IMO, an Exception should be thrown only when it is outside correctable situation. User inputting an incorrect format is known and shouldn't throw any Exception.
Treat Exception like it's catastrophic (data center on fire, earthquake, etc.). This way, you will see the difference between handling "regular error" and "Exception".
And yes, throwing and catching Exception cost a lot of performance, best is to avoid them.
5,67942549
I'd agree with your logic in your example, however what exception do you think you are handling in your exception handling block vs your programmatic test?
I suspect your exception handling block is really a "just in case something happened".
So it really comes down to the exception handling rule.
If you don't need to handle an exception and its not across a distinct architectural boundary don't handle it.
If its on the edge of a component boundary you might want to wrap it, placing the original in the inner exception.
If the functionality was being called from code you would either want to test the outcome with some status representation such as a response (HRESULT is a prime example of that. 0 == SUCCESS, != 0 == failure) or use exceptions.
Testing for programmatic errors or component failures is where you would use exceptions, if you are validating input from the user on a UI you might want to simply use logic and return status codes to help communicate the error to the user.
Finally think about localization too.
If you ripple an English error message up through the system and present it to your French speaking user that wouldn't be useful and you don't want to start parsing strings at your UI to generate the French version, so exceptions are the way to go as long as the payload of the exception has enough information to generate a useful error message for the user to take corrective action.
Use status code where you have a tight coupling between the components and the calling component knows what to do in the different status conditions.
BTW You might want to log the stack trace as well as just the message using ToString() as it will give you more helpful information to resolve the issue.
in that case, i'd actually say the try/catch is unnecessary, as your if is more than adequately handling your error
but the bottom one is the style i beleive should be used for more complicated situations
In your case I would just return the error message (first example), because throwing an exception only to catch it 3 line below seems a bit odd.
A completely different thing is that I usually avoid returning error codes when possible - when I have an error situation, I through an exception and I catch it at the highest level possible. In this way the code is not littered with error handling everywhere and it is much easier to see the business logic. In your case (if you control it of course) the method that returns success could have thrown an exception in case of failure, and you wouldn't have to ask this question at all :)
It is true that Exceptions are expensive in C#, so they shouldn't be abused. Having said that, when you have an error, the 50ms or so hit in performance is usually irrelevant, so I tend to use them to keep the code clean.
18.1k1980149
Extract the duplicated code out into a function, if you feel repeating yourself is a problem.
error_code_t fail (string message) {
logError(message);
return someErrorM
if (success) {
return someSuccessM
return fail("User input not correct format");
catch (Exception ex) {
return fail(ex.Message);
To be honest, I wouldn't worry about duplicating a couple of lines in the same function.
33.8k367118
Your Answer
Sign up or
Sign up using Google
Sign up using Facebook
Sign up using Stack Exchange
Post as a guest
Post as a guest
By posting your answer, you agree to the
Not the answer you're looking for?
Browse other questions tagged
Stack Overflow works best with JavaScript enabledprotel 99se 原理图转为PCB时出现Exception occurred in EDS:Synchronize Design异常信息，该怎么处理？_百度知道
protel 99se 原理图转为PCB时出现Exception occurred in EDS:Synchronize Design异常信息，该怎么处理？
提问者采纳
一）Protel99导入pcb时出现Exception Information Exception Occurred In，出错的是有 “-” 号的那个元件，另一个最后带 “-” 号，因为在网络表里面每个元器件引脚的表示方式都是： Note：后来发现在有一个差分输入的地方：“元件名”+“-”+“引脚序号”： EDS，所以我把文件名改掉，最后不要以“-”号结尾就没问题了。（三）Protel的库有些是以lib格式存在的，但有些库却保存在工程ddb文件里面：After any system crash it is good practice to save your ，一个元件的名字后面带 “+”号：Lgnore：Quit，所以有时候你想直接搜索某个库就无法搜到：解决办法，某个元件的引脚序号莫名其妙多一个负号等异常符合。（二）在原理图导成PCB的时候出现错误，不知道是不是Protel的一个bug：将PCB中的库移除后：Quit application 。解决办法：lgnore exception and return to：synchronize design ，确定没有此错误了再把库添加进来。元件名最后以负号结尾可能和后面表示连接的“-”号一起构成了其他符合.You well be prompted save
提问者评价
其他类似问题
为您推荐：
其他1条回答
关了再开，不行重装。。这都问
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁