Re: Error handling
From: Malcolm (malcolm_at_55bank.freeserve.co.uk)
Date: 04/23/04
- Next message: Arthur J. O'Dwyer: "Re: Arithmetic on function address"
- Previous message: Ziggy: "Re: strange case of void main"
- In reply to: Alberto Giménez: "Re: Error handling"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 23 Apr 2004 22:18:06 +0100
"Alberto Giménez" <algibe@teleline.es> wrote in message
> I don't mean to put the function name, but including what the
> function does, as an example, let's imagine a function that creates a
> socket for a server to "hear" on it. Let's name that function
> "create_socket" that function calls to another function called
> "socket", another called "bind" and some others. If that
> "create_socket" fails, my 2 ways of handling the errors are:
>
> 1) say the caller which sub-call failed, for example, return E_BIND > if
bind fails, or E_SOCK if socket call fails, and the caller print a
> useful? message saying something like:
> "couldn't create socket" or "couldn't bind server to a port",
> indicating that "create_socket" failed by the "socket" call or by the
> "bind" call.
>
> 2) don't mind about sub-call errors, and the caller of the
> "create_socket" function should say something like:
> "couldn't create a server socket", indicating a general error on
> "create_socket".
>
This really isn't a solved problem. In C++ you should throw exceptions,
which means that high-level code will always catch an error from where it
occurred. However it won't necessarily know the particular function in which
it occurred.
I think you can look at the issue this way. There are three types of error
a) When you can't get an IO resource needed
b) When input is badly formed
c) When the program runs out of memory.
If you separate out IO then you are left with error types b) and c). With a
few exceptions, such as functions that take input to be parsed by a grammar,
if you have a type b) error then that is a mistake by the calling
programmer. In a debug environment you should assert() fail. In a user
environment things are more difficult - basically something has gone wrong
and there is no good solution. You can terminate the program with a "CD
dirty" message if you like.
A type c) error is more a theoretical than a practical problem on modern
systems if you are asking for a small amount of memory. If the system won't
give you 1Kb for a buffer then you can be pretty sure that well before then
it will have generated "memory low" warnings. So it doesn't really matter
what you do, since the error-hnadling code will be executed too infrequently
to make any difference to the user.
If you are allocating a large amount of memory then of course the situation
is different - it's quite possible that the computer will be genuinely out
of memory. So you need to pass an "out of memory" flag up the control stack.
Note that the user, or even debugging programmer, doesn't really need to
know where you ran out of memory. There's nothing wrong with the function
itself, it just doesn't have resources to execute.
- Next message: Arthur J. O'Dwyer: "Re: Arithmetic on function address"
- Previous message: Ziggy: "Re: strange case of void main"
- In reply to: Alberto Giménez: "Re: Error handling"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
