On Error not called when invoking server method (throws exception in try-catch with this.HandleError )

[Blażej Szajrych]

Hi,

I am using XSockets 4.2.

I have it runing and the connection and invocation of methods is ok.

The time came to add some error handling notifications. So with respect to the documentation I am using the

HandleError(ex)

method from within a catch block. 

Ok so I have the client side  in javascript like this:

   

         soundPlayer.onopen = function (connection) {
                console.log("Connected to XSockets using native IIS WebSockets.", connection);
            };
            soundPlayer.onerror = function (err) {
                console.log(err);
            };

The onopen works fine. The onerror never gets called.

On the server side I simply invoke the HandleError for test purposes (I have already prepared a PostSharp attribute to divide the error notification concern):

     

        try
        {
            throw new ArgumentException();
        }
        catch (Exception ex)
        {
            this.HandleError(ex);
        }

I want to have notifications of errors of problematic calls on the server.

I also did try to write a C# client and hook up to the OnError event and it also does not trigger.
I have prepared a small project to ilustate my issue or perhaps some lack of knowledge at this point.

A try-catch in scope of the client call (C# client -> but I would like to achieve this in java script) also does not work as expected.
On the other hand when I try to connect to a non exsiting controller the OnError gets called.

So how to make this work?

Thanks in advance.

[Ulf Björklund]

Hi

You cant "catch" server errors in a client by just using try/catch.

All communication is async so the errors have to be sent back like all other communication using pub/sub or rpc/rmi.

We might have to update the docs since it seems to be unclear how to use the "HandleError" method.

Here is a sample... I wrote a simple controller named "foo" and then added a method called "boom". In the "boom" method I throw and exception that I catch and call the "HandleError" method.

When the "HandleError" method is called it will invoke the event "OnError" so you have to listen to that event.

The reason for us not sending back exceptions to the calling client on controller level is that you might expose information that you do not want clients to see.

So it is up to you to decide what to so...

Some code.

public class Foo : XSocketController

{

    public Foo()

    {

        this.OnError += (sender, args) =>

        {

            //Do whatever you want to do when a exception occurs on server side

            //1. Log

            Composable.GetExport<IXLogger>().Error(args.Exception, "An exception occurred");

            //2. Tell error interceptors

            ErrorInterceptorsQueue.Push(args.Exception);

#if DEBUG

            //3. If in debug also tell the client... Might not do that in release since bad people could get more info than you want them to have

            this.Invoke(args.Exception.Message, XSockets.Core.Common.Globals.Constants.Events.Error);

#endif

        };

    }

    public void Boom()

    {

        try

        {

            throw new Exception("Booooooom exception");

        }

        catch (Exception ex)

        {          

            //This will trigger the OnError event on the controller

            this.HandleError(ex);

        }

    }

}

As you can see I only send back the error in debug mode... I have no idea what you want to do, but if you want to always send back the error just do so.

To test this I started the server in debug mode and connected with putty, then I called the "boom" method on the "foo" controller from putty.

This will of course send the exception back since I was in debug mode.

Regards

Uffe

[Ulf Björklund]

Another thing btw.

I do not understand the sentence Connected to XSockets using native IIS WebSockets.

That is not the case if you use XSockets.

Just wanted to point that out.

Regards

Uffe

[Blażej Szajrych]

Thanks for the explanation.

First of all Connected to XSockets using native IIS WebSockets. This is possibly some copy/paste I made for logging purposse during some XSocket/other research.

Now its all clear for me on the approach of handling errors.
I think in my situation I should inform about an invalid state when an "initilaization exception" occurs" - so that no operations are possible at that time and re-initialization is needed.
And with respect to the above code I think i can do that using the PUB/SUB on the state. 

As to catching errors client side during the invocation I found this in the docs (http://xsockets.net/docs/4/c-sharp):

//using XSockets.Core.XSocket;
//using XSockets.Core.XSocket.Helpers;


try
{
    var stocks = conn.Controller("stockticker").Invoke<IEnumerable<Stock>>("GetStocks");
    foreach (Stock stock in stocks.Result)
    {
        Console.WriteLine("Symbol: {0} price: {1}", stock.Symbol, stock.Price);
    }
}
catch (Exception ex)
{
    Console.WriteLine("Error invoking GetStocks: {0}", ex.Message);
}

Is this misleading or am I misreading it (and it is server side buisness logic ?)?

[Ulf Björklund]

Hi, that makes sense!

The code you pasted is client side code, but the try/catch is for catching any errors that might occur in the client lib, not the server side.

pub/sub patterns is great, but I prefer rpc/rmi with the combination of state since that enables you to target any client(s) based on the knowledge you have about the connections.

But it all depends on what you are building, sometimes the combination of pub/sub and rpc/rmi is the best.

I understand why most web developers used to request/response wants to call the server and wait for the answer (like in the sample you copied). That is rarely used in XSockets (although the support is there) since everything is asynchronous and the waiting for the result is forcing the client to "wait" for the result. Sometimes though, this is very useful :)

If you want to send information about "init exceptions" and inform the client that an action have to be performed I would avoid using the "OnError" and instead send a message based on a topic so that it is easier to handle the logic.

Regards

Uffe

[Blażej Szajrych]

Hi,

Great thanks for the explanation. I have two qestions though -> one of which is an issue I am struggling with.

1. The client side C# example I gave tries to get the stocks. What will happen if the server will throw an exception while getting the stocks? Some kind of "ServerErrorException" (As you said server side errors will not be handled so I won't have the knowldede about the exceptions but some error->exception indication should be there right?)

2. I am using the PUB/SUB pattern to notify about a currently playing song information. This works fine when I connect to the controller and then initialize the player and when a song changes I get the info.
 The problem is when the page is loaded and there is a song playing. I checked what is the issue and initially (even when called after OnConnected) the controller subscribers for the topic count is zero.So initially I get 0 (or n-1 with respect to opened connections) Subscribers while I expect at least 1.
 When should I invoke the publish to inform the newly connected client about the state so that the subscription is valid? I am using angular with xSocketsProvider (but I see the problem is server side during the initial connection ).

Many thanks for all the info.

[Ulf Björklund]

Hi

1. If you are waiting for the result on the client by actually having a return value in the method you call you will get a exception when the timeout occurs (in the C# client).
   Exceptions in the server will not be sent back by default since that could expose security issues in your application to evil people...
   I would send information about the exception back with RPC if needed. As mentioned earlier I would avoid using the synchronous call since that is like forcing a half-duplex call (request/response) which actually sucks.
   If you are new to asynchronous messaging it will feel awkward at first, but after a while it feels so much easier than the "old" way of communicating.
   
   If you need a sample of what I mean with "sending the info back with RPC", let me know. There are times when synchronous communication is needed, but it is very rare and it does not sound like you need it (but I might be wrong).
2. Would really need to see some code to know what goes wrong, or if there are any mistakes in the code. But I would recommend RPC for this kind of logic since that will be much easier than pub/sub in this case. Maybe the right decision is a mix of rpc and pub/sub, but you will def. wanna use rpc in the OnOpened method

I will be happy to point you in the right direction, but you have to provide some code samples. You can contact me on uf...@xsockets.net if you do not want to post your code in here.

Regards

Uffe