Experimental Physics and
Industrial Control System

[email protected] (Jeff Hill) · Fri, 19 Nov 1999 11:53:05 -0700

All,

This message is addressed to persons developing CA client
side tools (and application developers that prefer to get detailed
diagnostic messages).

Attached is a CA exception handler replacement that is based on
the default handler in the CA client lib. The users get a message with
the information they need to solve problems, but abort() isn't called
so your CA client side code continues to run after a CA exception
with a severity higher than warning occurs.

Unfortunately, the replacement that is provided in CA client tools
sometimes throws away some really crucial diagnostic information.

You can edit this version to take out lines with dots if you
don't like them, but perhaps it is good to have some consistency
between CA clients? Leaving out some of the additional information below
is real unfriendly to the users I think because they will get,
for example, DB put fail messages but they wont know the inappropriate
data type that was the root cause of the problem. I also like
to see the file name and line number in messages because when
users report problems over E-mail I know exactly what part of
the code is involved. Note that the ca client/server code sometimes
generate ECA_INTERNAL error messages and the file name and line number
are the _only_ way to determine what part of the code is generating
the ECA_INTERNAL exception. Therefore if you leave out this
information you make my job more difficult. The args.ctx string
contains miscellaneous exception context information which can be
very crucial to otherwise baffled application developers.

Perhaps I should just have a call in the CA client library -
ca_disable_exeception_aborts() - so that the default exception
handler can be used.

Changing topics:
Persons developing CA client applications have asked for the
capability to replace the function that gets called when CA prints
a diagnostic message so messages don't go to stderr and they go to
some log file instead. This capability was provided in
the form of ca_replace_printf_handler().

Perhaps Marty will get the same request with
errlogPrintf() when it is used more often in standalone applications.
If this functionality is added then I can base the client lib on
errlogPrintf() while remaining backwards compatible with
ca_replace_printf_handler()? If so I could eliminate some
redundant code and reduce interdependency between the
client and server libraries.

Jeff

static void exceptionCallback (struct exception_handler_args args)
{
	if (args.chid && args.op != CA_OP_OTHER) {
        exceptionCallbackFormated  (
            args.stat,
            args.pFile,
            args.lineNo,
            "%s - with request chan=%s op=%ld data type=%s count=%ld",
		    args.ctx,
		    ca_name (args.chid),
		    args.op,
		    dbr_type_to_text(args.type),
		    args.count);
	}
	else {
        exceptionCallbackFormated   (
            args.stat,
            args.pFile,
            args.lineNo,
            args.ctx);
	}
}

static exceptionCallbackFormated  (long ca_status, const char *pfilenm,
                                       int lineno, const char *pFormat, ...)
{
    va_list             theArgs;
    static const char   *severity[] =
    {
        "Warning",
        "Success",
        "Error",
        "Info",
        "Fatal",
        "Fatal",
        "Fatal",
        "Fatal"
    };

    va_start (theArgs, pFormat);

    errlogPrintf (

"CA.Client.Diagnostic..............................................\n");

    errlogPrintf (
        "    %s: \"%s\"\n",
        severity[CA_EXTRACT_SEVERITY(ca_status)],
        ca_message (ca_status));

    if  (pFormat) {
        errlogPrintf ("    Context: \"");
        errlogVPrintf (pFormat, theArgs);
        errlogPrintf ("\"\n");
    }

    if (pfilenm) {
        errlogPrintf(
            "    Source File: %s Line Number: %d\n",
            pfilenm,
            lineno);
    }

    errlogPrintf(

"..................................................................\n");

    va_end (theArgs);
}

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System