-
-
Save codereflection/3859562 to your computer and use it in GitHub Desktop.
[HttpPost] | |
public ActionResult Edit(DonorViewModel model) | |
{ | |
try | |
{ | |
var donor = db.Donors.Get(model.Donor_ID); | |
model.CreatedOn = donor.CreatedOn; | |
model.DonorType_ID = donor.DonorType_ID; | |
model.ModifiedOn = DateTime.Now; | |
SetupEditViewData(model); | |
db.Donors.Update(model); | |
return RedirectToAction("Index"); | |
} | |
catch (Exception ex) | |
{ | |
ModelState.AddModelError(string.Empty, ex.Message); | |
return View(model); | |
} | |
} |
I see your point. Would any of these work?
- Add a generic message to the ModelState Errors and optionally log the exception.
- Map the few errors you expect to more user friendly messages (maybe with a simple hashtable).
Or, you could just leave it as "good enough." If it's an internal app and your users will get the point, then I don't see anything wrong with it in this case.
Thanks for the response. :) I think I'll probably go with your first suggestion. The trouble is this is not an internal app, but rather used by PTA parents who can have the entire spectrum of computer knowledge.
Oh, In that case, you should just have the ValidationSummary display your cell number and email address. :P
Well, two questions:
-
What do you expect the users to do with the Model Error?
-
Do you still display the model even if there are errors?
The only thing the users can do is report the error.
I would still display the model values on error.
Line #20 - This is sending a general exception message to the ModelState just so that it will be displayed via Html.ValidationSummary. It feels very wrong to me. However, I don't want to build up infrastructure for displaying possibly none model related errors to the user for this very small application.
Examples of what could go into ModelState.AddModelError: SQL error such as a DateTime exception, or a more general error such as a SQL command or connection timeout.