I am using Apache Ignite 2.7.5 as Server and thin client in .Net core.
When I'm doing operation related to cache put, get and load, etc .net core application automatically getting to crash.
So I want to handle exception inside for loop particular exception coming like for example IgniteCheckedException, BinaryInvalidTypeException, ClassNotFoundException, etc then throw from catch block and exit for loop otherwise continue for loop iteration if only Exception block.
public async void loadData(string configPath,List<JObject> dataList)
{
using (var ldr = _ignite.GetDataStreamer<string, Employee>(cacheName))
{
foreach (var item in parsedObjectList)
{
try
{
JObject keyObj = new JObject();
foreach (var keyName in keyArray)
{
keyObj[keyName.ToString()] = item[keyName.ToString()];
}
var serializerSettings = new JsonSerializerSettings { NullValueHandling = NullValueHandling.Ignore };
JsonConvert.PopulateObject(item.ToString(), emp, serializerSettings);
string json = JsonConvert.SerializeObject(keyObj, Formatting.None);
string base64EncodedKey = Convert.ToBase64String(Encoding.UTF8.GetBytes(json));
await ldr.AddData(base64EncodedKey, emp);
}
catch (IgniteCheckedException ex)//how to handle here
{
throw;
}
catch (BinaryInvalidTypeException ex)//how to handle here
{
throw;
}
catch (ClassNotFoundException ex)//how to handle here
{
throw;
}
catch (Exception ex)
{
//continue for loop if data parsing ,some normal exception
Console.WriteLine(ex);
}
}
}
}
Anyone suggests me, how to achieve this one in .net core c# application.
When you catch an exception from a thin .net client, the best course of action, as with any such client, to retry attempt, if it fails again, wait for some time, close connection, open new connection, try again. If that also fails, rethrow (write to log, fail current operation).
Related
In SignalR v2, I used code like this (below) to handle exceptions that happened when my connections failed. What is the equivalent in SignalR v3? Does SendAsync or SendAsyncCore throw some exception should connections fail or serialization fail?
private async void ManagerOnUserRemoved(UserDto userDto)
{
try
{
await Context.Clients.All.MyFunc(userDto);
}
catch (InvalidOperationException) { }
catch (AggregateException) { }
}
I didn't see any exceptions listed here: https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.signalr.client.hubconnectionextensions.sendasync?view=aspnetcore-3.0
Update: I have the same question for the calls from the client-side (to InvokeCoreAsync et al).
In SignalR V3 use HubException to capture exceptions that contain sensitive information, such as connection information.
https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.signalr.hubexception?view=aspnetcore-3.1
private async void ManagerOnUserRemoved(UserDto userDto)
{
try
{
await Context.Clients.All.MyFunc(userDto);
}
catch(Exception ex) {
//Now check exceptions what you want by exception message or exception code
}
}
With this code you can handle all exceptions, or you can do this:
hubConnection.Error += ex => Console.WriteLine("Error: {0}", ex.Message);
I think it will be help
I am using Apache Ignite 2.7.5.
I don't know whether is there any way is there or not but trying to handle .net thin client exception,but i am not approaching to correct way,how to catch ignite java one throwable exception in c# .net catch block.
code:
public async void loadData(string configPath,List<JObject> dataList)
{
using (var ldr = _ignite.GetDataStreamer<string, Employee>(cacheName))
{
try
{
await ldr.AddData(base64EncodedKey, emp);//from this line i am getting exception on console but not able to catch
}
catch (Exception ex)//how to catch here java one throw exception
{
}
}
}
Any one suggest me correct approach to get exception in catch block.
I'm incorporating telemetry into my product on all service requests, unfortunately that includes exceptions. A problem I'm having is I surround my requests with a try-catch and if it's successful I log the request and if there's a catch I log the exception than throw the exception so that it still gets propagated up so that it can be debugged. A problem I'm having is that with try-catch I lose all the original data from the original exception caught by my try-catch, which I think would be nice to propagate back up.
public void someFunction(object data)
{
try
{
var response = await request(data);
LogInformation(request: data, response: response);
}
catch (Exception e)
{
throw HandleAndLogException(data, e);
}
}
private HttpResponseException HandleAndLogException(object data, Exception e)
{
LogException(data: data, response: e.Message);
var resp = new HttpResponseMessage(HttpStatusCode.BadRequest) {
Content = new StringContent(e.Message)
};
return new HttpResponseException(resp);
}
So as you can see I create a new HttpResponseException and just append the message to it, but I'd rather propagate back up the exception thrown in it's entirety.
If you want to do something clever/evil, you can use the when keyword to introduce logging without breaking the stack trace on your exception.
See when contextual keyword in the C# reference on MSDN. It's supposed to be used as a filter (the method returns true or false, indicating whether that catch block should be used) but you can do whatever you want with
I think this is what you'd want, although I haven't tested it:
public void someFunction(object data)
{
try
{
var response = await request(data);
LogInformation(request: data, response: response);
}
catch (Exception e) when (HandleAndLogException(data, e))
{
throw;
}
}
private bool HandleAndLogException(object data, Exception e)
{
LogException(data: data, response: e.Message);
return true;
}
I'm following MVC pattern in my Application server. I'm trying to throw an exception but its not been properly thrown.
Here is the code from controller:
[HttpPost]
public IHttpActionResult PostAddSuperUser(SuperUserViewModel SU)
{
try
{
//more code
blHandler.addSuperUser((SuperUser)SU.user, SU.Password);
return Ok();
}
catch (EUserAlreadyExist ex)
{
var resp = new HttpResponseMessage(HttpStatusCode.NotAcceptable);
resp.Content = new StringContent(string.Format("Already exist ", SU.user.Mail));
resp.ReasonPhrase = "Already exist";
throw new HttpResponseException(resp);
}
Then the client side calls it as follow:
try{
HttpClient client = new HttpClient();
client.BaseAddress = new Uri("http://localhost:50687/");
HttpResponseMessage response = await client.PostAsJsonAsync<SuperUserViewModel>("/api/SuperUser/PostAddSuperUser", SUVM);
if (response.IsSuccessStatusCode)
{
new SuccesPupUp("", "SuperUser " + SupUserName + " was added");
}
this.Close();
}
}
catch (HttpResponseException Exc)
{
new ErrorPopUp("", Exc.Message);
}
According to this this I'm throwing it correctly, but when I run it I got this error
How can I fix it?
EDIT: I want to throw the exception to the client side, so as to it could ask the user for a new email address
The problem is within this block of code (seems obvious but bear with me):
catch (EUserAlreadyExist ex)
{
var resp = new HttpResponseMessage(HttpStatusCode.NotAcceptable);
resp.Content = new StringContent(string.Format("Already exist ", SU.user.Mail));
resp.ReasonPhrase = "Already exist";
throw new HttpResponseException(resp);
}
Whats happening is that you are catching an EUserAlreadyExist exception from the above try and then throwing a new exception without an accompanying try-catch block. So this means that just because you threw an exception within a catch, it won't auto-magically catch it, you would have to have a separate try-catch within your catch
Going further with this, the client-side call to this try-catch also won't catch the thrown exception because they (the catch statements) are catching different types of exceptions than what is being thrown.
To fix it would require you catching the exception that is being thrown in this case a HttpResponseException exception. So that would mean your code might look something like this:
catch (EUserAlreadyExist ex)
{
try{
var resp = new HttpResponseMessage(HttpStatusCode.NotAcceptable);
resp.Content = new StringContent(string.Format("Already exist ", SU.user.Mail));
resp.ReasonPhrase = "Already exist";
throw new HttpResponseException(resp);
}
catch(HttpResponseException ex2)
{
//do something here with the exception
}
}
Server side code should not need to catch the exception and re-throw it - what's the point? Just let it bubble up to the client. That's the beauty and power of exceptions. The trouble is MVC wants to return a View or an HTTP Status Code, not rich, strongly typed exception information.
You appear to be using MVC pattern in a rich client (client-server) situation, which makes no sense. MVC is best suited to thin client situations whereby the server serves up views, and the client just renders them. When you have a rich client, the MVVM pattern makes more sense. Server can serve up View Models (data) and client can take over all the user interaction, views etc.
Consider using an MVVM approach (with WCF) instead of MVC. Then both client and server will have a common understanding of the exception types that can be thrown. Server can throw, client can catch, easy.
Your client code would then be as simple as:
try
{
c.AddSuperUser(SUVM);
}
catch (Exception e)
{
// etc
}
where c is the WCF client proxy.
I have to process items off a queue.
Deleting items off the queue is a manual call to Queue.DeleteMessage. This needs to occurs regardless of whether or not the processing succeeds.
var queueMessage = Queue.GetMessage();
try
{
pipeline.Process(queueMessage);
}
catch (Exception ex)
{
try
{
Logger.LogException(ex);
}
catch { }
}
finally
{
Queue.DeleteMessage(queueMessage);
}
Problem:
On failure, I log the error to some data store. If this logging fails (perhaps the data store is not available), I still need the message to be deleted from the queue.
I have wrapped the LogException call in another try catch. Is this the correct way or performing thing?
Following code is enough. finally blocks execute even when exception is thrown in catch block.
var queueMessage = Queue.GetMessage();
try
{
pipeline.Process(queueMessage);
}
catch (Exception ex)
{
Logger.LogException(ex);
}
finally
{
Queue.DeleteMessage(queueMessage);//Will be executed for sure*
}
The finally block always executes, even if it throws an unhandled error (unless it end the app). So yes.