I am using aspnet core & angular and I have:
public async Task<Response> CreateClient(Client input)
{
input.Name = null;
Response result = new Response();
try
{
await repo.InsertAsync(input);
await unitOfWorkManager.Current.SaveChangesAsync();
}
catch (Exception ex)
{
if (ex.InnerException != null)
result.ErrorMessage = ex.InnerException.Message;
else
result.ErrorMessage = ex.Message;
}
return result;
}
based on the fact that I set input.Name = null when await repo.SaveChangesAsync(); is called it throws an exception (Name is required).
I catch the exception and have custom logic to return the response with error in it.
Problem is that in client I still get this ugly popup:
which I dont want to show for custom forms. The purpose of this logic inside the app service is to avoid using the popups for CRUD and errors and instead develop using my own controls.
11 Answer(s)
-
0
In fact, although you caught the exception of
await unitOfWorkManager.Current.SaveChangesAsync(). the unit of work still callsSaveChangeswhen the method call ends. causing a new exception.You can consider using user friendly exceptions. https://aspnetboilerplate.com/Pages/Documents/Handling-Exceptions#userfriendlyexception
-
0
@maliming How can I use user friendly exception in my scenario since the unitofwork throws exception?
-
0
First of all, I think that the verification of model parameters and the verification of other data should not be handled by EF. You should verify it before storing it in the database. The error information of the database is also difficult for users to understand.
When you detect a parameter or other business problem, just throw an exception.
Throw new UserFriendlyException("message")Please refer to:https://aspnetboilerplate.com/Pages/Documents/Handling-Exceptions#userfriendlyexception
-
0
Maliming you are correct this was just quick test code to show my problem. I already did what you suggested
Throw new UserFriendlyException("message")but still I get the popup on angular which I dont want to display.I have my own logic on how to handle errors on client and I dont want to use this ugly popup
-
0
You can implement your own
abp.message.errorhttps://github.com/aspnetzero/aspnet-zero-core/blob/dev/angular/src/assets/abp-web-resources/abp.sweet-alert.js#L36
-
0
https://github.com/aspnetboilerplate/abp-ng2-module/blob/master/src/abpHttpInterceptor.ts#L233
All requests are intercepted, maybe you can refer to abp's interceptor to implement your own interceptor.
-
0
No I dont want that solution which is not convenient at all. I have dozens of CRUD forms. Some of the form needs to handle errors differently.
I want to get the response back as usual and will handle the errors by my self. This is not a solution for me
-
0
It is possible yes but that means that I have to go on all aspnetzero crud forms (users, organization units, roles etc..) and also change their error handling behavior. The way aspnetzero team implemented error handling is not scalable and convenient at all. Their implemenation is problematic as it guides the developer to a specific direction rather than give the freedom to choose whatever is needed based on client requirements. Such a little thing but so important is implemented in a strict way. Shame
-
0
Hi @antonis
It is not related to client side but it is related to server side actually (related to https://support.aspnetzero.com/QA/Questions/5990).
I think an exceptinon is thrown even if you use a try-catch block is the problem here.
-
0
@ismcagdas I think the problem is on the design of aspnetboilerplate and aspnetzero exception and error handling.
As I explained earlier:
It is possible yes but that means that I have to go on all aspnetzero crud forms (users, organization units, roles etc..) and also change their error handling behavior. The way aspnetzero team implemented error handling is not scalable and convenient at all. Their implemenation is problematic as it guides the developer to a specific direction rather than give the freedom to choose whatever is needed based on client requirements. Such a little thing but so important is implemented in a strict way.
-
0
Correctness is more important than flexibility.
try { using (var uow = unitOfWorkManager.Begin(TransactionScopeOption.RequiresNew)) // Add this scope { await repo.InsertAsync(input); await unitOfWorkManager.Current.SaveChangesAsync(); await uow.CompleteAsync(); // Add this } }
