I have a simple Action on a controller which returns a PDF.
Works fine.
public FileResult GetReport(string id)
{
byte[] fileBytes = _manager.GetRepor
I would change the return type of your method to ActionResult.
public ActionResult GetReport(string id)
{
byte[] fileBytes = _manager.GetReport(id);
if (fileBytes != null && fileBytes.Any()){
string fileName = id+ ".pdf";
return File(fileBytes, MediaTypeNames.Application.Octet, fileName);
}
else {
//do whatever you want here
return RedirectToAction("GetReportError");
}
}
If you want to "communicate to the browser" that there was an error, the standard "HTTP way" is to return status code 500, especially if your request is invoked using Ajax, so that you can gracefully handle the exception.
I would suggest to simply throw an Exception
when no report found for the provided id
:
public FileResult GetReport(string id)
{
// could internally throw the Exception inside 'GetReport' method
byte[] fileBytes = _manager.GetReport(id);
// or...
if (fileBytes == null || !fileBytes.Any())
throw new Exception(String.Format("No report found with id {0}", id));
return File(fileBytes, MediaTypeNames.Application.Octet, fileName = id+ ".pdf");
}
Explicitly redirecting to an error page or returning a ViewResult
is not the best approach in ASP.NET MVC as this is usually the role of the HandleError
filter (which is applied by default) that can be easily configured to either redirect or render some View with the Exception details (while still maintaining HTTP status 500).
This is all true assuming that a failure to fetch a report is indeed considered an exception. If it's not (for example, if we expect some report to not have an available file to dump), explicitly returning a Redirect/View
result is totally acceptable.
The FileResult
class inherits from ActionResult
. So, you can define your Action like this:
public ActionResult GetReport(string id)
{
byte[] fileBytes = _manager.GetReport(id);
string fileName = id + ".pdf";
if(fileBytes == null || fileBytes.Length == 0)
return View("Error");
return File(fileBytes, MediaTypeNames.Application.Octet, fileName);
}
Another workaround for handling prerequisites is to split download process into two stages. First is to check preconditions in server side method which is executed as ajax/post method.
Then if these preconditions are fulfilled you can start download request (e.g. in onSuccess callback where it is checked the return value indicating fulfillment) in which (on server side) you will handle potential exceptions in a way as it was described in above posts.