We Keep Coding

possible exceptions from IClientProxy.SendAsync (from Microsoft.AspNetCore.SignalR)

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

Apache Ignite thin client Exception handling

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).

AX 2012 R3 Visual Studio project C# parsing errors

I am writing a wrapper for SSHnet dll from renci (https://sshnet.codeplex.com/), so I can fetch files from a sFTP server via Dynamics AX periodically.
When I catch errors in C# project for example in a try catch statement how can I parse the error message back to AX?
Options I thought of;
Should I put the error message in a string variable and read the string in Dynamics AX?
Write errors to the event log on the AOS / client?

The easiest way to pass error to AX is a rethrow it in C#
catch (Exception ex)
{
// Do special cleanup, logging etc.
throw;
}
and catch it in AX
catch (Exception::CLRError)
{
ex = ClrInterop::getLastException();
if (ex != null)
{
ex = ex.get_InnerException();
if (ex != null)
{
error(ex.ToString());
}
}
}

Sync conflict handling in Azure Mobile Services: ad hoc vs sync handler

When not using a "sync handler", one needs to catch sync errors for push and pull.
PUSH:
Samples say to catch MobileServiceInvalidOperationException, MobileServicePushFailedException and Exception:
try {
await client.SyncContext.PushAsync();
}
catch (MobileServiceInvalidOperationException ex) {
// ...push failed
// ...do manual conflict resolution
}
catch (MobileServicePushFailedException ex) {
// ...push failed
// ...do manual conflict resolution
}
catch (Exception ex) {
// ...some other failure
}
PULL:
Samples say to catch MobileServiceInvalidOperationException and Exception:
try {
await syncTable.PullAsync("allitems", syncTable.CreateQuery());
}
catch (MobileServiceInvalidOperationException ex) {
// ...pull failed
}
catch (Exception ex) {
// ...some other failure
}
SYNC HANDLER:
Errors are processed in .ExecuteTableOperationAsync(). Samples say to catch
MobileServiceConflictException, MobileServicePreconditionFailedException and Exception.
FINALLY A QUESTION(S):
I hope I covered all the possible exceptions types above.
If I use a sync handler, does that mean I don't need to try-catch the push/pull/purge/etc. operations? Samples I've seen are a little confusing as they include everything (ad hoc resolution and sync handler) in the same project...

You should always place push/pull/etc. operations in a try/catch block. There is always a risk that an Exception you haven't thought of (including the network going away, for example) will happen.

Try inside catch to ensure finally executes

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.