I'm trying to return two different models at the same function in C#, I don't know if it's possible.
public async Task<<Model1>, <Model2>> GetLocation()
{
string url = Utils.LimbleConnection.SetUrl("/locations");
try
{
return Model1;
} catch (HttpRequestException httpEx)
{
return Model2
}
}
Perhaps setting up to return both models. On success, the first item is true, second has the first model, third as null and vis versa for failure. On failure the code below returns a new instance of the model, you need to decide what the data comes back as e.g. populated with whatever you want.
Here I'm simply doing a proof of concept with Entity Framework, you can adapt to your web code.
public static async Task<(bool success, Customer customers, ContactTypes)> GetDataAsync()
{
try
{
await using var context = new CustomerContext();
return (true, context.Customer.FirstOrDefault(), null);
}
catch (Exception exception)
{
// log exception then return results
return (false, null, new ContactTypes());
}
}
Caller code deconstructs the method.
public async Task Demo()
{
var (success, customers, contactTypes) = await DataOperations.GetDataAsync();
if (success)
{
// use customers
}
else
{
// use contact type
}
}
You can try using a Tuple:
private Tuple<string, int> Method()
{
var tuple = new Tuple<string, int>("String Value", 0);
return tuple;
}
Related
My Api Service is in .NET and my client side is in React.js. I use axios.post to send parameters and retrieve datas from .NET. I want to see error details on react.js side when something happened in service side. Example codes are below;
[HttpPost]
public ConcreteAccrument CalculateDepositAmount([FromBody] DepositAmountParameters depositAmountParameters)
{
ConcreteApplication application = depositAmountParameters.application;
int multiplier = depositAmountParameters.multiplier;
bool forceCalculation = depositAmountParameters.forceCalculation;
long registryInfoOid = depositAmountParameters.registryInfoOid;
long subscriberRegistryOid = depositAmountParameters.subscriberRegistryOid;
try
{
Com.BS.WaterSupplyAndSeverage.Services.WaterSupplyAndSewerage wssService = new Com.BS.WaterSupplyAndSeverage.Services.WaterSupplyAndSewerage();
return wssService.CalculateDepositAmount(application, multiplier, forceCalculation, registryInfoOid, subscriberRegistryOid);
}
catch (BSException e)
{
FileLogger.Error(CLASS_NAME, "CalculateDepositAmount", e.Message, e.StackTrace, application, multiplier, forceCalculation);
BSCommunicationException commException = new BSCommunicationException();
commException.Id = e.Id;
commException.ExceptionMessage = e.ExceptionMessage;
throw new FaultException<BSCommunicationException>(commException, new FaultReason(commException.ExceptionMessage));
}
catch (Exception e)
{
FileLogger.Error(CLASS_NAME, "CalculateDepositAmount", e.Message, e.StackTrace, application, multiplier, forceCalculation);
BSCommunicationException commException = PrepareCommunicationException(e);
throw new FaultException<BSCommunicationException>(commException, new FaultReason(commException.ExceptionMessage));
}
}
There are some details in throw new FaultException at first catch(BSException e). It's not a system error. For example, data is null or some value are missing when first catch works. And second catch is system error. But in that code all catches return 500 error in React.Js side. All I want is to see all detail in first catch on React.js side. When I use "return error" in catch then I get convert error because my class return an object.
Here my react.js code;
export const CalculateDepositAmount = (APPLICATION,MULTIPLIER,FORCE_CALCULATION,REGISTRY_INFO_OID, SUBSCRIBER_REGISTRY_OID, SuccessOperation, FailedOperation) => {
return () => {
const body = { application:APPLICATION,multiplier:MULTIPLIER,forceCalculation:FORCE_CALCULATION,registryInfoOid:REGISTRY_INFO_OID, subscriberRegistryOid:SUBSCRIBER_REGISTRY_OID};
console.log("bodyFormData",body)
axios.post('https://localhost:44396/api/CalculateDepositAmount', body)
.then( async response => {
SuccessOperation({ CALCULATED_DEPOSIT_AMOUNT_DATA: await response.data });
})
.catch(() => {
FailedOperation({ CALCULATED_DEPOSIT_AMOUNT_DATA: null })
});
}
}
I am assuming that this is not asp.net core / 5 / 6, but vanilla 4.x
One thing you can do is change the method signature to IHttpActionResult, so you can return different status codes, with varying payloads back to the client:
public IHttpActionResult CalculateDepositAmount([FromBody] DepositAmountParameters depositAmountParameters)
{
try
{
var result = wssService.CalculateDepositAmount(application, multiplier, forceCalculation, registryInfoOid, subscriberRegistryOid);
return Ok(result);
}
catch (BSException e)
{
return BadRequest(e.Message)
//or
//return StatusCode(418)
}
catch (Exception e)
{
}
}
You can tailor the response to the client much better to your needs, instead of return either the object or an exception. You can find the full list of here:
https://learn.microsoft.com/en-us/previous-versions/aspnet/dn314678(v=vs.118)?redirectedfrom=MSDN
Another approach that will require some more refactoring, is to change the return type of your service to some sort of Result object, that indicates, whether it is a successfull operation or if a problem occured.
For example take this CommandResult example:
public class CommandResult<T>
{
private CommandResult(T payload) => Payload = payload;
private CommandResult(string failureReason)
{
FailureReason = failureReason;
}
public string FailureReason { get; }
public string Message { get; }
public bool IsSuccess => string.IsNullOrEmpty(FailureReason);
public T Payload { get; }
public static implicit operator bool(CommandResult<T> result) => result.IsSuccess;
public static CommandResult<T> Success(T payload)
=> new(payload);
public static CommandResult<T> Fail(string reason)
=> new(reason);
}
In your service you can now do the following:
public Commandresult<ConcreteAccrument> CalculateDepositAmount(DepositAmountParameters depositAmountParameters)
{
try
{
var result = // do the calculation
return CommandResult<ConcreteAccrument>.Success(result);
}
catch (BSException e)
{
return CommandResult<ConcreteAccrument>.Fail(e.Message);
}
catch (Exception e)
{
return CommandResult<ConcreteAccrument>.Fail(e.Message);
}
}
Now your controller simply has to decide, if it was successfull or not:
public IHttpActionResult CalculateDepositAmount([FromBody] DepositAmountParameters depositAmountParameters)
{
var result = wssService.CalculateDepositAmount(application, multiplier, forceCalculation, registryInfoOid, subscriberRegistryOid);
if(result.IsSuccess) // or simply if (result)
{
return Ok(result.Payload);
}
return Exception(result.FailureReason); //or whatever suits best.
}
The context: An AspNetCore controller I've been asked to maintain contains methods similar to the following:
// Get api/Foo/ABCXXX/item/12345
[HttpGet("{accountId}/item/{itemNumber}")]
public async Task<ActionResult<ItemViewModel>> GetFoo([FromRoute] string accountId, [FromRoute] int itemNumber)
{
if (string.IsNullOrWhiteSpace(accountId))
{
return BadRequest("accountId must be provided");
}
if (itemNumber < 0)
{
return BadRequest("itemNumber must be positive");
}
if (!await CanAccessAccountAsync(accountId))
{
return Forbid();
}
// Returns null if account or item not found
var result = _fooService.GetItem(accountId, itemNumber);
if (result == null)
{
return NotFound();
}
return result;
}
// GET api/Foo/ABCXXX
[HttpGet("{accountId}")]
public async Task<ActionResult<IEnumerable<ItemViewModel>>> GetFoos([FromRoute] string accountId)
{
if (string.IsNullOrWhiteSpace(accountId))
{
return BadRequest("accountId must be provided");
}
if (!await CanAccessAccountAsync(accountId))
{
return Forbid();
}
// Returns null if account not found
var results = _fooService.GetItems(accountId);
if (results == null)
{
return NotFound();
}
return Ok(results);
}
You may assume that there are more than 2 such methods with very similar parts.
Looking at this code makes me itchy—there appears to be a lot of repetition, but the repeated parts can't be extracted to their own methods because they contain return statements.
To me, it would make sense for these early exits to be exceptions rather than return values. Say, for the sake of argument, that I define an exception to wrap an IActionResult:
internal class ActionResultException : Exception
{
public ActionResultException(IActionResult actionResult)
{
ActionResult = actionResult;
}
public IActionResult ActionResult { get; }
}
Then I can extract some specific validations:
private void CheckAccountId(string accountId)
{
if (string.IsNullOrWhiteSpace(accountId))
{
throw new ActionResultException(BadRequest("accountId must be provided"));
}
}
private async Task CheckAccountIdAccessAsync(string accountId)
{
if (!await CanAccessAccountAsync(accountId))
{
throw new ActionResultException(Forbid());
}
}
private void CheckItemNumber(int itemNumber)
{
if (itemNumber < 0)
{
throw new ActionResultException(BadRequest("itemNumber must be positive"));
}
}
And rewrite the controller to use them:
// Get api/Foo/ABCXXX/item/12345
[HttpGet("{accountId}/item/{itemNumber}")]
public async Task<IActionResult> GetFoo([FromRoute] string accountId, [FromRoute] int itemNumber)
{
try
{
CheckAccountId(accountId);
CheckItemNumber(itemNumber);
await CheckAccountIdAccessAsync(accountId);
// Returns null if account or item not found
var result = _fooService.GetItem(accountId, itemNumber);
if (result == null)
{
return NotFound();
}
return Ok(result);
}
catch (ActionResultException e)
{
return e.ActionResult;
}
}
// GET api/Foo/ABCXXX
[HttpGet("{accountId}")]
public async Task<IActionResult> GetFoos([FromRoute] string accountId)
{
try
{
CheckAccountId(accountId);
await CheckAccountIdAccessAsync(accountId);
// Returns null if account not found
var results = _fooService.GetItems(accountId);
if (results == null)
{
return NotFound();
}
return Ok(results);
}
catch (ActionResultException e)
{
return e.ActionResult;
}
}
To get this to work, I had to wrap the controller bodies in a try to unwrap the action result from the exception.
I also had to revert the return types to IActionResult—there are reasons I may prefer not to do that. The only thing I can think of to address that problem is to go more specific with the exceptions and catches, but this seems only to shift the WET-ness from the validation code to the catch blocks.
// Exceptions
internal class AccessDeniedException : Exception { ... }
internal class BadParameterException : Exception { ... }
// Controller
private void CheckAccountId(string accountId)
{
if (string.IsNullOrWhiteSpace(accountId))
{
throw new BadParameterException("accountId must be provided");
}
}
private async Task CheckAccountIdAccessAsync(string accountId)
{
if (!await CanAccessAccountAsync(accountId))
{
throw new AccessDeniedException();
}
}
private void CheckItemNumber(int itemNumber)
{
if (itemNumber < 0)
{
throw new BadParameterException("itemNumber must be positive");
}
}
// Get api/Foo/ABCXXX/item/12345
[HttpGet("{accountId}/item/{itemNumber}")]
public async Task<IActionResult> GetFoo([FromRoute] string accountId, [FromRoute] int itemNumber)
{
try
{
...
}
catch (AccessDeniedException)
{
return Forbid();
}
catch(BadParameterException e)
{
return BadRequest(e.Message);
}
}
// GET api/Foo/ABCXXX
[HttpGet("{accountId}")]
public async Task<IActionResult> GetFoos([FromRoute] string accountId)
{
try
{
...
}
catch (AccessDeniedException)
{
return Forbid();
}
catch (BadParameterException e)
{
return BadRequest(e.Message);
}
}
There's a few simple things you can do. No need to go overboard at this point.
First and foremost, checking whether accountId is null or whitespace is completely superfluous. It's part of the route; if something isn't stuck in there, you wouldn't get here in the first place.
Second, you can make judicious use of route constraints where appropriate. For example, for your itemNumber being positive:
[HttpGet("{accountId}/item/{itemNumber:min(0)}")]
Though, honestly, I'm not sure something like /XXXX/item/-1 would even work in the first place. Regardless, specifying a min value will cover you.
Third, your CanAccessAccount check should actually be handled via resource-based authorization, built-in to ASP.NET Core.
Long and short, if you use what's already available to you, you actually don't need to do much additional validation, in the first place, negating the need to find some way to "factor it out".
I have the following method (abbreviated for simplicity):
public Task CreateAsync(TUser user)
{
using (var connection = new SqlConnection(_connection))
{
return Task.FromResult(connection.Execute("CreateUser", param, commandType: CommandType.StoredProcedure));
}
}
I would like to incorporate a try-catch block, so I can log any potential Sql errors.
public Task CreateAsync(TUser user)
{
var result = ???; // what is the return type here?
try
{
result = FromResult(connection.Execute("CreateUser", param, commandType: CommandType.StoredProcedure));
}
catch(SqlException sqlEx)
{
// log error here
}
return result;
}
I guess I'm not sure what the return type of Task is?
You should use async methods instead of Task.FromResult.
I'm assuming you are using Dapper or some kind of framework that extends SqlConnection.
I have no idea what the stored procedure returns. If the return value doesn't matter then the code should look like this.
public async Task CreateAsync(TUser user)
{
try
{
await connection.ExecuteAsync("CreateUser", param, commandType: CommandType.StoredProcedure);
}
catch(SqlException sqlEx)
{
// log error here
}
}
if it does matter then (example with bool):
public async Task<bool> CreateAsync(TUser user)
{
bool result;
try
{
await connection.ExecuteAsync("CreateUser", param, commandType: CommandType.StoredProcedure);
result = true;
}
catch(SqlException sqlEx)
{
// log error here
result = false;
}
return result;
}
I like to design my methods with only one return statement, for a various number of reasons (I see it as best practice).
But how can i have a mvc controllers actionresult create a result object, where i can put both a HttpStatusCodeResult into, aswell as a normal Json result?
Both of them inherits from ActionResult.
Edit:
An example of what i have now, but would like to change to only 1 return statement, would be like this:
public ActionResult Test(string inputString = "stack")
{
try
{
int carrots = int.Parse(inputString);
return Json(new { Data = carrots }, JsonRequestBehavior.AllowGet);
}
catch (Exception)
{
return new HttpStatusCodeResult(400);
}
}
You could inherit and extend the JsonResult class which adds the Http status code.
public class JsonHttpStatusResult : JsonResult
{
private readonly HttpStatusCode _httpStatus;
public JsonHttpStatusResult(object data, HttpStatusCode httpStatus)
{
Data = data;
_httpStatus = httpStatus;
}
public override void ExecuteResult(ControllerContext context)
{
context.RequestContext.HttpContext.Response.StatusCode = (int)_httpStatus;
base.ExecuteResult(context);
}
}
Now you can use it like a normal Jsonresult in non-error conditions, and in error conditions, it can be:
var errorModel = new { error = "There was an error" };
return new JsonHttpStatusResult(errorModel, HttpStatusCode.InternalServerError);
You simply send response code along with your response:
Response.StatusCode = Convert.ToInt32(System.Net.HttpStatusCode.InternalServerError);
return Json(new { Data = carrots }, JsonRequestBehavior.AllowGet);
If you really just want one return, the simple way of doing it is something like this:
public ActionResult SomeMethod()
{
ActionResult result;
try
{
result = TryGetTheCorrectResult();
}
catch
{
result = MakeSomeHttpStatusCodeResult();
}
return result;
}
It really is a matter of taste whether you find that "better" than
public ActionResult SomeMethod()
{
try
{
return TryGetTheCorrectResult();
}
catch
{
return MakeSomeHttpStatusCodeResult();
}
}
Shorter methods with less local variables can also contribute to code quality, but it all depends on taste I guess.
I'm trying to create a service to get all my boxes from the database like this :
[HttpGet]
[Route("GetBoxes/")]
[ResponseType(typeof(ResultQuery))]
public async Task<IHttpActionResult> GetBoxes()
{
try
{
var boxes = db.Boxes.ToList<Box>();
foreach (Box in boxes)
{
status.Add(GetBox(box));
}
return Ok(ConvertToResultQuery(boxes));
}
catch (Exception e)
{
return InternalServerError(e);
}
}
public GenericBox GetBox(Box box)
{
try
{
//Do a lot of stuff with the database
return genericBox;
}
catch (Exception e)
{
return null;
}
}
public static ResultQuery ConvertToResultQuery(object result)
{
return new ResultQuery(result);
}
Where ResultQuery has just one object attribute containing the result of my service.
The service is simple but for some reason it gives me this error when I try it in postman :
An asynchronous module or handler completed while an asynchronous operation was still pending.
VisualStudio also gives me a warning advising to use await but I don't understand where I should put it.
Your GetBoxes method is an async method, but your GetBox is not.
You say that you are doing db work inside the GetBox method but everything in that method is running synchronously. Consider changing the signature of GetBox to:
public async Task<GenericBox> GetBox(Box box)
{
try
{
//Do a lot of stuff with the database
//'await' database calls here
return genericBox;
}
catch (Exception e)
{
return null;
}
}
Then in your GetBoxes method change your foreach to a Task.WhenAll() instead:
var result = await Task.WhenAll(boxes.Select(x => GetBox(x)));
The result variable will be a Task
If you do not want to mess with Task.WhenAll(), you can simply await the GetBox method inside your loop:
status.Add(await GetBox(box));