In my WebAPI 2.1 application I am processing inserts like this:
[Route("Post")]
public async Task<IHttpActionResult> Post([FromBody]City city)
{
if (!ModelState.IsValid)
{
return BadRequest(ModelState);
}
try
{
db.Exams.Add(city);
await db.SaveChangesAsync(User, DateTime.UtcNow);
}
catch (Exception ex)
{
var e = ex;
return BadRequest("Error: City not created");
}
return Ok(city);
}
I use something similar for updates and deletes. I think I should do something more meaningfull with
the exceptions but I am not sure where to start with how to handle these. I looked at elmah but it said it deals with unhandled exceptions. Does this mean I should not be catching exceptions like this?
Can someone give me some
pointers as to if what I have is okay and also should I be logging exceptions and how?
What you are doing is not "bad", it's just a bit verbose and won't scale well if you have many try/catch blocks all over your code. When an exception is raised, you decide what to do so, returning a bad request response is fine if it's really a bad request. There are many things you can return, depending on what went wrong. But you have to handle what to do when exceptions are thrown all over your code, so maintaining this logic scattered all over your code can quickly become a problem.
It's better to utilise asp.net web api's exception handling framework. For example, take a look at these articles:
http://www.asp.net/web-api/overview/web-api-routing-and-actions/exception-handling
http://www.asp.net/web-api/overview/web-api-routing-and-actions/web-api-global-error-handling
The idea is to centralise your logic in a global exception handler and to use that as the only place in your code where you have to worry about this. The rest of your code will be throwing exceptions and everything will be coming through your exception handler/filter/etc., depending on what you decide.
For example, I have created my own exception types (e.g. CustomExceptionA, CustomExceptionB, etc.) and when I throw an exception of a type I know exactly how to handle it in one place and perform a certain bit of logic. If I want to change the way I handle a particular exception type, then there's only one place I have to make a change and the rest of the code will be unaffected.
The second article link above also includes a global exception logger to log such exceptions.
Related
I have a global error trap in the Application_Error method of Global.asax that writes any unhandled exception to a log file.
Is there anyway of reporting the variable names and their values as part of the exception report?
Unless you do something really tricky with Aspect-Oriented Programming, you pretty much need to make sure that you manually introduce any relevant information into the stack trace when exceptions are thrown. For example:
public void DoSomething(int number, string name)
{
try
{
...
}
catch (Exception e)
{
throw new Exception("Error occurred while doing something: " +
new {number, name}, e);
}
}
This way, the number and name will be included in the stack trace when this exception trickles up to the top level.
Edit
After reading David Stratton's answer, I felt the need to expand on this a little. I get the sense that even some very experienced C# programmers haven't learned some of the tricks that I've learned.
First of all, I wanted to point out that the exception-handling system in .NET was designed with the idea of an InnerException specifically for this purpose (providing additional information at various points of the stack trace), and it is not at all hacky to do. However, you should definitely provide the exception as the innerException constructor parameter, rather than appending e.ToString() to the new exception's message.
Secondly, based on various comments and answers I've read on StackOverflow, as well as my own experience, it's best to:
Avoid catching an exception if there's nothing specific you plan to do with it.
When you catch an exception, rethrow it unless you know why the exception was thrown and you're in a scope where you know how to gracefully retreat from what you were trying to do. Simply pretending nothing went wrong is asking for more trouble down the road.
When re-throwing exceptions, either just throw; to preserve the original exception's stack trace, or include the original exception as a new exception's InnerException.
Consistently log exceptions that don't get re-thrown. This will generally only happen at the UI level, so you can tell the user something unexpected happened rather than allowing the program to crash.
Finally, I wanted to mention that the anonymous type declaration syntax is ideal for this kind of thing because it is very concise and it will automatically produce a string that uses the given variable names and values. For example, new {number, name}.ToString() might produce "{ number = 1, name = Test }".
We do this in some cases, but in a roundabout way. We use a try/catch at the granular level and if we want to pass the exception up to the global error handler, we build the error message. For example:
int someCounterValue = 0;
string someStringValue = "Some string we want to track to send to the global error handler."
private void SomeFunction()
{
try
{
someStringValue = "in the try block";
someCounterValue = 1.5 // should thrown an exception
}
catch(Exception ex)
{
throw new Exception("Error in SomeFunction. someStringValue = " + someStringValue + "; someCounterValue = " + someCounterValue.ToString() + "\r\nException details: " + ex.ToString());
}
}
It's a lot of work so we really don't do this very often. Usually our error handling is better handled at the local level but in those very rate cases where you want to pass it off to the global error handler, this is about the only way we've found, since the variables would be out of scope otherwise, and therefore, inaccessible.
An easier/less hack-like option would be to set up a static class in your web app called ErrorLogger or something similar, and just handle the exceptions better locally and pass them up to the global handler ONLY when you can't do it locally.
In my opinion (and in the way we do it here by policy) a global error handler should be used to catch exceptions that you forgot to handler better at a more granular level. It should NOT just be an easy way to be lazy about proper exception handling.
Also it feels like a hack to me, so if anyone has a better option I'd like to know it, too.
Executing the line:
Response.Redirect("Whateva.aspx", true);
Results in:
A first chance exception of type 'System.Threading.ThreadAbortException' occurred in mscorlib.dll
An exception of type 'System.Threading.ThreadAbortException' occurred in mscorlib.dll but was not handled in user code
The exception is because of the "true" part, telling it to end the current request immediately.
Is this how it should be?
If we consider:
Exceptions are generally considered heavy, and many times the reason for ending the request early is to avoid processing the rest of the page.
Exceptions show up in performance monitoring, so monitoring the solution will show a false number of exceptions.
Is there an alternative way to achieve the same?
You're right regarding the fact that the developer should avoid raising of (and catching) exceptions since the execution runtime consumes time and memory in order to gather the information about the particular exception. Instead he (or she) should simply not let them occur (when it's possible).
Regarding the Response.Redirect: this behavior is "by-design" but you might want to use a well-known workaround. Please read this KB article.
-- Pavel
One approach I generally take in this scenario is to not end the response during the response, but to follow it immediately with a return (or other flow control). Something like this:
Response.Redirect("Whateva.aspx", false);
return;
This depends on where the redirect is taking place in your logic flow, of course. However you want to handle it is fine. But the idea is that, when you want to end the response on the redirect anyway, then exiting the method in question via a return isn't out of the question.
One approach I've seen people take in this matter quite often, and it should go without saying that this is to be avoided but for completeness I'm going to say it anyway (you never know who may stumble upon this question later via Google, etc.), is to catch and swallow the exception:
try
{
Response.Redirect("Whateva.aspx", true);
}
catch (Exception ex)
{
// do nothing
}
This, of course, should not be done, for a number of reasons. As I inferred from your description of exceptions, you undoubtedly already know that this would be bad practice. But, as I said, it's worth noting this fact in the answer.
To work around this problem, use one of the following methods:
For Response.End, call the HttpContext.Current.ApplicationInstance.CompleteRequest method instead of Response.End to bypass the code execution to the Application_EndRequest event.
For Response.Redirect, use an overload, Response.Redirect(String url, bool endResponse) that passes false for the endResponse parameter to suppress the internal call to Response.End.
For example:
Response.Redirect ("nextpage.aspx", false);
If you use this workaround, the code that follows Response.Redirect is executed.
For Server.Transfer, use the Server.Execute method instead.
from:
http://support.microsoft.com/kb/312629/en-us
Same link posted by Volpav.
Regards.
Is there any performance problem or something else about letting the exception to propagate, or it is better to write it like this
try
{
}
catch
{
throw;
}
If you're not going to handle the exception it's better to have nothing rather than what you propose. All that does is add the overhead of catching and then rethrowing the same exception.
If you can handle the exception do so, but then don't propagate it further up the call stack.
The only time I can think of when I'd have that kind of empty catch\rethrow logic is when I'd want to log the exception in some way, otherwise I'd just let it propagate.
EDIT: added the missing word empty
Could anyone tell me why a problem in the noun model would not be caught by this try catch?
I have tried this on two different controller methods now, and both times, even if the linq2sql doesn't allow the data to be saved, the code never jumps into the catch block.
I've watched the noun object in the middle of the trace, and the isvalid property is false, but the modelstate isvalid is true. Either way, the code never jumps into the catch block.
I'm pulling my hair out about this. I feel like it will be something really silly.
The code all works similar to nerd dinner.
NounRepository nounRepository = new NounRepository();
Noun noun = new Noun();
try
{
UpdateModel(noun);
nounRepository.Add(noun);
nounRepository.save();
}
catch (Exception ex)
{
ModelState.AddRuleViolations(noun.GetRuleViolations());
return View(noun);
}
return View(noun);
Update
I have just added this code, and now the rules are coming back to the front end fine, so it just seems that the try catch isn't catching!
UpdateModel(noun);
if (!noun.IsValid)
{
var errors = noun.GetRuleViolations();
ModelState.AddRuleViolations(noun.GetRuleViolations());
return View(noun);
}
nounRepository.Add(noun);
nounRepository.save();
I'd rather not have to add code in this manner though, as it seems like an unnecessary duplication.
You faced logical change in mvc - validation here do not throw exceptions. Indeed, you need to check it using if statement.
I doubt that exception is happening - you need to catch linq2sql exception anyway, code is correct. Also there is high a chance that inside 'save' or 'add' you have another catch - this is quite common mistake
Programming Rule #1: catch ain't broken (AKA: SELECT ain't broken).
If you're really in doubt, open up the Debug menu, choose "Exceptions", then tick the box for "Common Language Runtime Exceptions" under "Thrown." This will cause the debugger to break on all first-chance exceptions. If the debugger doesn't break during your update, then the exception is never getting thrown in the first place.
Don't forget to untick when you're done, as the behaviour gets pretty annoying under normal usage.
P.S. Never catch System.Exception. Catch the specific type(s) of exception(s) that you know might actually be thrown.
Are you doing something in another thread? That is often a cause exceptions not being caught.
Which type exception checking required in linq inside try/catch block while performing CRUD(create,read,update,delete) OPERATIONS
for eg:
try {
db.SubmitChanges(ConflictMode.ContinueOnConflict);
}
catch (ChangeConflictException e) {
foreach (ObjectChangeConflict occ in db.ChangeConflicts) {
// All database values overwrite current values.
occ.Resolve(RefreshMode.OverwriteCurrentValues);
}
}
If it's not well-documented what exceptions will be thrown in normal use-case scenarios (and I can't say off the top of my head what will be thrown in your situation), I suggest trying to break it by performing operations you know will fail, and then add the exception that's thrown to the try/catch block.
If anything, trying to break your own code is a good debugging exercise, as it exposes problems that are likely to occur giving you a chance to recover gracefully.