Exceptions vs Error return values

Exceptions vs Error return values

[Hambut]

I'm currently trying to get to grips with winsock programming.  As
part of this process I'm trying to put together a slightly higher
level binding to the thin one provided with Gnat.

The 'thin' binding provides a lot of functions returning an
integer. The value of this integer encodes a whole range of possible
errors.  I want to replace this 'C'-esque way of doing stuff with Ada
exceptions; my question is "What is a sensible guideline for choosing
between exceptions and error return codes?"

Looking at some of the error codes there are a couple that seem
natural exceptions. For example when
1  Winsock hasn't been initialised by a call to WSAStartup, or when
2  Winsock detects that the network has fallen over.

In both cases Winsock is not able to fulfil the service to the client
(in the case of 1 because of improper use by the client, and in the
case of 2 due to some external event), so the client needs to be
notified in no uncertain terms that something is wrong.

But there are other cases that are less obvious, for example when
1  The Winsock call returns no data, or when
2  The operation has been blocked by another windows socket operation.

In both cases Winsock is still able to fulfil the services it's
offering.  The client may continue to use its services, but it is
advisable for the client to take some kind of action.

Would it be a sensible guideline to relate the use of exceptions to
the severity of error (for example as described in table below)?

Exception/  : Error Type
Error Value : 
------------:------------------------
Exception   : Server package about to overwrite all memory with garbage
Exception   : Server package can not fulfil offered services
Error Value : Server package can not fulfil called service with
            :  provided parameters
Error Value : Service results in a 'not-expected' but correct result
            :  (e.g. returning a null host name) 

I've had a delve through Barnes, and through the Ada95 style guide,
and neither really helped to clear my mind on this point.


Any thoughts gratefully received...

Cheers,

Hambut.

p.s.  I suppose you could almost do both; a child package providing
'exceptions' and another child providing 'error values'.  That way the
client could choose the most appropriate mechanism for the
application.  Would this be useful, or just overkill?

Re: Exceptions vs Error return values

[tmoran]

> I'm currently trying to get to grips with winsock programming.  As
> part of this process I'm trying to put together a slightly higher
> level binding to the thin one provided with Gnat.
> ...
> Would it be a sensible guideline to relate the use of exceptions to
> the severity of error (for example as described in table below)?
   In Claw.Sockets (www.rrsoftware.com) we aways raise an exception.
There are a very few standard ones, eg. Busy_Error, Not_Valid_Error,
Not_Found_Error, but a lot of things raise Windows_Error.  In that
case there's a routine you call to get the specific error code -
normally, but not always, in 10004 .. 11004.

> 1  Winsock hasn't been initialised by a call to WSAStartup, or when
  Claw.Sockets also tries to reduce the number of possible errors.
For instance, it automatically does the WSAStartup call the first
time you do something with winsock, and a Finalize routine cleans up.

Re: Exceptions vs Error return values

[Stephen Leake]

hfrumblefoot@yahoo.com (Hambut) writes:

> I'm currently trying to get to grips with winsock programming.  As
> part of this process I'm trying to put together a slightly higher
> level binding to the thin one provided with Gnat.

A laudable goal.

> The 'thin' binding provides a lot of functions returning an integer.
> The value of this integer encodes a whole range of possible errors.
> I want to replace this 'C'-esque way of doing stuff with Ada
> exceptions; my question is "What is a sensible guideline for
> choosing between exceptions and error return codes?"

I always raise an exception whenever the function cannot do what the
caller expected.

On the other hand, I don't define a different exception for every
error. There are two mechanisms to encode different errors; either use
Ada.Exceptions.Raise_Exception with a message string, or provide a
function that returns an error code. In the case of Windows stuff,
raising Windows_Error, and allowing the user to get the Windows error
code, is sufficient.

> <snip>
> p.s.  I suppose you could almost do both; a child package providing
> 'exceptions' and another child providing 'error values'.  That way the
> client could choose the most appropriate mechanism for the
> application.  Would this be useful, or just overkill?

Overkill.

-- 
-- Stephe

Re: Exceptions vs Error return values

[Ted Dennison]

In article <uzo9dgxtf.fsf@gsfc.nasa.gov>, Stephen Leake says...
>
>hfrumblefoot@yahoo.com (Hambut) writes:
>
>> The 'thin' binding provides a lot of functions returning an integer.
>> The value of this integer encodes a whole range of possible errors.
>> I want to replace this 'C'-esque way of doing stuff with Ada
>> exceptions; my question is "What is a sensible guideline for
>> choosing between exceptions and error return codes?"
>
>I always raise an exception whenever the function cannot do what the
>caller expected.
>
>On the other hand, I don't define a different exception for every
>error. There are two mechanisms to encode different errors; either use
>Ada.Exceptions.Raise_Exception with a message string, or provide a
>function that returns an error code. In the case of Windows stuff,
>raising Windows_Error, and allowing the user to get the Windows error
>code, is sufficient.


If there is another call that can be made to get the exact error code, I'd
usually just provide a binding to that. Otherwise, I'm with Steven in that I
don't like to create tons of different exceptions. I ususally just create one
named "Error" (eg: Sockets.Error). I also used to tack any extra info onto the
exception message. The problem I found with doing that is that there are often
arbitrary limits on the maximum length of that message. What I prefer to do
these days is define an error message string (as Ada.Strings.Unbounded), and
provide that to the user.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Exceptions vs Error return values

[Freddy]

Hambut schrieb:
> 
> I'm currently trying to get to grips with winsock programming.  As
> part of this process I'm trying to put together a slightly higher
> level binding to the thin one provided with Gnat.
> 
> The 'thin' binding provides a lot of functions returning an
> integer. The value of this integer encodes a whole range of possible
> errors.  I want to replace this 'C'-esque way of doing stuff with Ada
> exceptions; my question is "What is a sensible guideline for choosing
> between exceptions and error return codes?"

In my own bindings (a port from Modula-2) I prefered return values as 
 - it is more effectiv
 - it prevents the programmer from writing a lot of exception handlers
(for nearly every call), you would have to
   catch (and handle) all IP related exception (you shouldn't use the
"others" choice)
 - it's more readable
 - it is sometimes not relevant what the actual returncode was (some of
the codes are not really exceptual)

This is my personal preference, others may differ.


  procedure Ping (Host : STRING; RC : out Integer) is
    s : Socket;
    Result : Integer;
    Data : STRING := "        abcdef";
    Buffer : STRING (1..255);
    Buffer_Len : Integer;
    Host_IP : IPV4;
    Sender : IPV4;
    Sender_Port : Integer;
  begin
    RC := No_Error;
    
    Init (Result);
    if Result /= No_Error then RC := Result; return; end if;

    GetHostAddress (Host, Host_IP, Result);
    if Result /= No_Error then RC := Result; Cleanup (Result); return;
end if;

    CreateRawSocket (Protocoll_ICMP, s, Result);
    if Result /= No_Error then RC := Result; Cleanup (Result); return;
end if;
  
    Fill_Header (1, 1, Data);
    
    SendTo (s, Data, Host_IP, 0, RC, Timeout_Immediate);    
    if Result /= No_Error then RC := Result; Cleanup (Result); return;
end if;

    RecvFrom (s, Buffer, Buffer_Len, Sender, Sender_Port,  Result,
1000);    
    if Result /= No_Error then RC := Result; Cleanup (Result); return;
end if;
    
    Cleanup (Result);  
    if Result /= No_Error then RC := Result; end if;
  end Ping;