«

Hi, I'm thinking of having a seperate module in my project that deals
with the exceptions and errors as they occur in a C program. Is this a
good idea ? I thought of doing this because it is getting really
repetitive to have the same thing in my code over and voer again eg.
if malloc fails then:

int *p;

p = malloc(sizeof(int) * 5);

if(p == NULL)
{
perror("malloc has failed");
exit(EXIT_FAILURE);
}

This situation may arise in many places in different contexts so what
I would like to do is identify such cases and have a seperate module
with a switch case that takes an error flag as an input and makes the
decision based on it. The error flags would represent the various
errors/exceptions like malloc failure, failure in opening file, scanf
failure, floating point exceptions , array out of bounds etc. I would
also like to print the name of the module where the exception occuerd
as well as the line number. Is there a function in C which provides
this facility ?

In comp.lang.c, pereges wrote:

> Hi, I'm thinking of having a seperate module in my project that deals
> with the exceptions and errors as they occur in a C program. Is this a
> good idea ?

IMHO, for a small number of common exceptions and/or errors, this is a good
idea, but it breaks down when you want to generalize it, or later add
behaviour changes.

[snip]
> This situation may arise in many places in different contexts so what
> I would like to do is identify such cases and have a seperate module
> with a switch case that takes an error flag as an input and makes the
> decision based on it.

For a limited number of errors or exception conditions, this would work.
But, it isn't scalable, and your initial design/implementation may not
properly handle exceptional processing.

For example, your initial design may simply report the error and call
exit(). Subsequently, you may find reason to report the error and return
back to the caller, or report the error and request a user decision, or
silently handle the error and return. Each one of these changes would
necessitate corresponding behavioural changes in your common handler, along
with a (possibly) ever-growing list of function arguments (function,
message, output-log-file FILE, user-input-action-message,
user-input-options, user-input-file FILE, user-input-via-GUI flag,
exit/return code, abnormal-termination-with-core-dump flag, ...).

You need to be careful about how you design the initial function, and under
what circumstances it will be used, otherwise accomodating your "exception
handler" function may consume more programming resources than the rest of
the program.

[snip]

> Is there a function in C which provides this facility ?

Not in ISO standard C, no.

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

On 19 May 2008 at 18:01, Pietro Cerutti wrote:
> Standard C doesn't, but GCC provides the __FILE__ and __LINE__ macros,
> which expand to the filename and line number where they appear.

You could also just dump core, which would give you access to a full
backtrace - very useful for debugging.

can someone please give a simple example demonstrating _FILE_, _LINE_
and _func_

On May 19, 11:27 pm, Pietro Cerutti <g...@gahr.ch> wrote:
> pereges wrote:
> > can someone please give a simple example demonstrating _FILE_, _LINE_
> > and _func_
>
> > cat filelinefunc.c
> #include <stdio.h>
> int main(void)
> {
> printf("%s:%d (%s)\n", __FILE__, __LINE__, __func__);
> return (0);}
>
> > ./filelinefunc
> filelinefunc.c:4 (main)
>

why the paranthesis for the last %s format specifier ?

Antoninus Twink wrote, On 19/05/08 19:14:
> On 19 May 2008 at 18:01, Pietro Cerutti wrote:
>> Standard C doesn't, but GCC provides the __FILE__ and __LINE__ macros,
>> which expand to the filename and line number where they appear.
>
> You could also just dump core, which would give you access to a full
> backtrace - very useful for debugging.

Unless the system does not produce a core dump or equivalent. Systems
which do not produce core dumps are quite common.
--
Flash Gordon

Lew Pitcher <> wrote in message
news:3e26f$4831c116$4c0a8b34$-Free...
> In comp.lang.c, pereges wrote:
>
> > Hi, I'm thinking of having a seperate module in my project that deals
> > with the exceptions and errors as they occur in a C program. Is this a
> > good idea ?
>
> IMHO, for a small number of common exceptions and/or errors, this is a
good
> idea, but it breaks down when you want to generalize it, or later add
> behaviour changes.

Hmmmm, well, not necessarily...I think you have to come up with
the right generalized scheme. At least I seem to have gained some
good practical coding speed using such a scheme.

> [snip]
> > This situation may arise in many places in different contexts so what
> > I would like to do is identify such cases and have a seperate module
> > with a switch case that takes an error flag as an input and makes the
> > decision based on it.
>
> For a limited number of errors or exception conditions, this would work.
> But, it isn't scalable, and your initial design/implementation may not
> properly handle exceptional processing.

I think the trick, as always with low-level support library functions, is
to abstract what you are doing over and over and over again in the
application,
and generalize it to the extent possible.

For errors, you have a severity level of error (warning, caution, etc.), a
logging/reporting "requirement", possible prompted user actions that may
still fail to fix the problem, and the application action that is taken if
the
problem cannot be solved by user action. Most, but not all, of these
can and should be handled generically at a lower-level...

> For example, your initial design may simply report the error and call
> exit().

Both of these can be handled in a low-level generic library function...

> Subsequently, you may find reason to report the error and return
> back to the caller,

IBID. As a matter of fact, the way I write my particular applications,
you are generally kicked out of the operation gracefully and returned
to a "menu" state to select another operation, with a timed "dialog"
asking the user if they want to continue with the application at all...

> or report the error and request a user decision,

IBID.

> or
> silently handle the error and return.

IBID, though you'd still probably want the temporary failure to
be logged...

> Each one of these changes would
> necessitate corresponding behavioural changes in your common handler,
along
> with a (possibly) ever-growing list of function arguments (function,
> message, output-log-file FILE, user-input-action-message,
> user-input-options, user-input-file FILE, user-input-via-GUI flag,
> exit/return code, abnormal-termination-with-core-dump flag, ...).

Well, I didn't say it would be EASY, just a little easier (maybe!)
than re-inventing all those wheels for EVERY possible error...and
you've really got to pick your specific and generic handling
carefully, and handle each at the appropriate level...

> You need to be careful about how you design the initial function, and
under
> what circumstances it will be used, otherwise accomodating your "exception
> handler" function may consume more programming resources than the rest of
> the program.

Well, if you're talking about exceptions AND errors, maybe (I'm
starting to be reminded of "try-catch" in other languages)...

> > Is there a function in C which provides this facility ?
>
> Not in ISO standard C, no.

What about "errno.h" and stuff like that?

---
William Ernest Reid

Pietro Cerutti wrote:
> ...
> A good example of this are, IMHO, Marc J. Rochkind's EC_*
> macros described in the "Advanced UNIX Programming" book.

Poor choice of namespace. Identifiers begining with E and
a capital letter are reserved whenever <errno.h> is included.

--
Peter

Hi

On May 19, 6:48 pm, pereges <Brol...@gmail.com> wrote:
> Hi, I'm thinking of having a seperate module in my project that deals
> with the exceptions and errors as they occur in a C program.

You might want to mimic the API of Glib:

http://library.gnome.org/devel/glib/...Reporting.html

It seems fairly extensible while remaining low level.

HTH
viza

On Mon, May 19, 2008 at 10:48:09AM -0700, pereges wrote:
> Hi, I'm thinking of having a seperate module in my project that deals
> with the exceptions and errors as they occur in a C program. Is this a
> good idea ? I thought of doing this because it is getting really
[snip]
> decision based on it. The error flags would represent the various
> errors/exceptions like malloc failure, failure in opening file, scanf
> failure, floating point exceptions , array out of bounds etc. I would
> also like to print the name of the module where the exception occuerd
> as well as the line number. Is there a function in C which provides
> this facility ?

I think it is important to make difference between
a bug (the programer made a mistake);
a failure (the system did not have the resources, a subtask is cancelled);
a fatal error (it does not make sense to continue the program);

bugs: the assert macro is just for bugs, it performs a check and
writes a message, that is meaningful for the programmer only.
(assert macros can be easily switched off in the production version,
where there will be no bugs)

failure: a function cannot carry out the task. It returns an error identifier
or throws an exception, if there is no error code in the interface.
If the interface has an error code, that has to propagate though a series
of function calls until it becomes meaningful to continue.

fatal error: very simple, one has to print a user friendly message and exit.
You will want to make a small function that prints to the gui/tui/console
or logfile.

Whereas it is trivial to use error codes returned by the functions, it is
quite cumbersome, since that has to be checked every time.

But there is a limited but reasonable exception handling in standard C.
1) longjmp/setjmp
If you wish, you can define a throw and a catch macro using the fact
that !setjmp() may form the controlling state of a for statement.
You cannot throw an object, but the function call hierarchy is wound up.
Personally I use this quite often in a tui based database application.

2) atexit.
This facilitates a graceful exit.
I am not quite sure, but I think you can call atexit from a function
registered using atexit and invoked by exit(). Than you can return
to a main loop using this method, too.

Hope that this makes (some) sense

Szabolcs