• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:

  • You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
  • You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
  • If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.

Previously on ".Net - Socket and 'defensive programming practices' ......"

Collapse

  • Guest's Avatar
    Guest replied
    Re: Net - Socket and 'defensive programming practices' ....

    That's exactly it OH.

    I've come across a couple of those problems, but I can't for the life of me remember them off the top of my head.

    I would expect MS advise us to use defensive programming just to stop numpty's from surrounding every line of code in try...catch blocks.

    Same reason they advise not to use shared methods and properties.

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Re: Net - Socket and 'defensive programming practices' ....

    Assuming .net syntax is like c++ the .connected is a property and not a function that is executed to check the status of the link. Thus the status will probably only change if the socket is closed properly by the remote end. If the remote end crashes then this end knows nothing about it until an attempt is made to send or read data.

    Personally won't bother with the .connected check. The .send() probably generates exception, may even have return type, if based on bsd socket calls, that indicates number of bytes written.

    "know nothing about .net" mode and don't give a @#%$ if I'm wrong.

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Net - Socket and 'defensive programming practices' ....

    Nice reply,
    the whole point is that the code should be written defensively, (without trying to teach egg-sucking), ie. if (something != null) then go ahead and access 'something', if it is null then handle that scenario accordingly (maybe with an exception etc.), but what is the point of having/exposing a 'Connected' property if it doesn't necessarily expose the 'Connected' property ?? surely if the client has disconnected then the 'connected' property should return false ??

    My code has try/catch/finally blocks in every single method, precisely to catch the exceptions to the normal program flow. I wouldn't expect to have to catch a SocketException if the client has disconnected surely ?? isn't that the reason for having a 'connected' property ??

    Grrrrrrrrrr

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Re: .Net - Socket and 'defensive programming practices' ....

    How the hell are we supposed to program defensively if we have to handle the disconnection of a Client Socket by trapping the applicable exception ??
    Not sure I understand the problem D.

    The MS advice to program defensively rather than simply relying on exception handling is good advice, but they don't mean it to apply right across the board.

    What in this case is wrong with trapping various socket-related exceptions in try...catch blocks and handling the error accordingly?

    Yes they're fairly resource heavy, but to what extent this is a problem depends on the nature of your application. In most of mine, the benefits of using them more often than not outway the costs, especially in precisely this kind of scenario.

    I've just this minute got back from a client site where they were getting similar errors when closing down the threads that handle their sockets. The solution was to wrap various parts of the socket code in try..catch blocks that check for ThreadState errors. The solution is elegant, solid, and not resource-intensive at all within the context of an application that elsewhere uses more defensive checks.

    <quote>
    There is no guarantee that the Socket is still Connected even if Connected returns true. A value of true simply means that the Socket was connected at the time of the last I/O operation.
    </quote>

    There are lots of little gotcha's like this in .Net. This particular one doesn't seem like much of a problem to me. Am I missing something?

    I've done lots of socket related stuff in .Net so feel free to carry on the discussion.

    Leave a comment:


  • Guest's Avatar
    Guest started a topic .Net - Socket and 'defensive programming practices' ......

    .Net - Socket and 'defensive programming practices' ......

    Hello all,
    it aint usual that I post a question, but this one has me stumped !! I am of the belief that we should always program 'defensively', as is Microsofts want. Exceptions are just that, exceptions to the programs normal flow, as they are expensive in terms of resources etc. we should program defensively and cater for invalid status(es) in our logic. With this in mind I have the following code (sorry about the formatting of it but this BB is sh!te and has re-formatted it as it wants)...

    if (m_objSocket != null)
    {
    m_objSocket.Send(System.Text.Encoding.ASCII.GetByt es("You are now connected!\r\n"));
    // *** Ensure that the Socket is Connected ***
    while (m_objSocket.Connected)
    {
    // *** Thread Processing ***
    m_objSocket.Send(System.Text.Encoding.ASCII.GetByt es("You are still connected!\r\n"));

    // *** Relinquish to the OS ***
    Thread.Sleep(100);
    }

    // *** ShutDown the Socket ***
    m_objSocket.Shutdown(SocketShutdown.Both);
    m_objSocket.Close();

    // *** Fire the Disconnection Event ***
    OnClientDisconnnection();
    }

    The problem is that the 'm_objSocket.Connected' always returns true, even when the Client app (Hyperterminal in my test case) has terminated, then a SocketException is thrown. In the MSDN documentation it says:

    <quote>
    There is no guarantee that the Socket is still Connected even if Connected returns true. A value of true simply means that the Socket was connected at the time of the last I/O operation.
    </quote>

    How the hell are we supposed to program defensively if we have to handle the disconnection of a Client Socket by trapping the applicable exception ??

    If anyone can throw any light on this I would be most grateful....

    Rgds,
    D

Working...
X