CODEWITHSUNDEEP
ctcpc89cvi
Johannes
Johannes

Reputation: 6717

How can i catch a runtime error in ansi C90

I am using the library Function ConnectToTCPServer. This function times out when the host is not reachable. In that case the application crashes with the following error: "NON-FATAL RUN-TIME ERROR: "MyClient.c", line 93, col 15, thread id 0x000017F0: Library function error (return value == -11 [0xfffffff5]). Timeout error"

The Errorcode 11 is a Timeout error, so this could happen quite often in my application - however the application crashes - i would like to catch this error rather than having my application crash.

How can i catch this runtime error in Ansi C90?

EDIT: Here is a Codesnippet of the current use:

ConnectToTCPServer(&srvHandle, srvPort, srvName, HPMClientCb, answer, timeout);

with

int HPMClientCb(UINT handle, int xType, int errCode, void *transData){
    printf("This was never printed\n");
    return errCode;
}

The Callbackfunction is never called. My Server is not running, so ConnectToTCPServer will timeout. I would suspect that the callback is called - but it never is called.

EDIT 2: The Callback function is actually not called, the Returnvalue of ConnectToTCPServer contains the same error information. I think it might be a bug that ConnectToTCPServer throws this error. I just need to catch it and bin it in C90. Any Ideas?

EDIT 3: I tested the Callbackfunction, on the rare occaision that my server is online the callback function is actually called - this does not help though because the callback is not called when an error occurs.

Upvotes: 2

Views: 1276

Answers (6)

Uri Cohen
Uri Cohen

Reputation: 3608

Looking in NI documentation, I see this:
"Library error breakpoints -- You can set an option to break program execution whenever a LabWindows/CVI library function returns an error during run time. "

I would speculate they have a debug option to cause the program to stop on run-time errors, which you need to disable in configuration, in compile time or in run-time.

My first guess would have been configuration value or compilation flag, but this is the only option I found, which is a run-time option:
// If debugging is enabled, this function directs LabWindows/CVI not
// to display a run-time error dialog box when a National Instruments
// library function reports an error.
DisableBreakOnLibraryErrors();

Say if it helped.

Upvotes: 3

chris
chris

Reputation: 4026

The documentation states that ConnectToTCPServer will return the error code. The callback is only called if the connection is established, disconnected or when there is data ready to be read.

The message you get states that the error is NON-FATAL, hence it shouldn't abort. If you're sure the code doesn't abort later it seems indeed like a bug in the library.

I'm not familiar with CVI, but there might be a (compile-/runtime-) option to abort even on non-fatal errors (for debugging purposes). If you can reproduce this in a minimal example you should report it to NI.

Upvotes: 0

Mike Sherrill 'Cat Recall'
Mike Sherrill 'Cat Recall'

Reputation: 95612

I'm not sure I understand you.

I looked at the documentation for the library function ConnectToTCPServer(). It returns an int; 0 means success, negative numbers are the error codes.

EDIT: Here is a Codesnippet of the current use:

ConnectToTCPServer(&srvHandle, srvPort, srvName, HPMClientCb, answer, timeout);

If that's really the current use, you don't seem to be trying to tell whether ConnectToTCPServer() succeeds. To do that, you'd need

int err_code;
...
err_code = ConnectToTCPServer(&srvHandle, srvPort, srvName, HPMClientCb, answer, timeout);

and then test err_code.

The documentation for ConnectToTCPServer()implies that your callback function won't be called unless there's a message from a TCP server. No server, no message. In that case,

  1. ConnectToTCPServer() should return a negative number.
  2. You should check the return value of ConnectToTCPServer().
  3. Finding a negative number there, you should do something sensible.

Did I understand the documentation correctly?

Upvotes: 1

CoreyStup
CoreyStup

Reputation: 1488

Theres no such thing as a general case of "catching" an error (or an 'exception') in standard C. Thats up to your library to decide what to do with it. Likely its logging its state and then simply calling abort(). In Unix, that signals SIGABRT which can be handled and not just exit()ed. Or their library may just be logging and then calling exit().

You could run your application under a utility like strace to see what system calls are being performed and what signals are being asserted.

I'd work with your vendor if you can't make any headway otherwise.

Upvotes: 2

unwind
unwind

Reputation: 399871

From the documentation, it seems you should get a call to your clientCallbackFunction when an error occurs. If you don't, you should edit your question to clarify that.

Upvotes: 1

Oliver Charlesworth
Oliver Charlesworth

Reputation: 272537

Normally, you should be able to simply check the return value. The fact that your application exits implies that something is already catching the error and asserting (or something similar). Without seeing any context (i.e. code demonstrating how you're using this function), it's difficult to be any more precise.

Upvotes: 0

Related Questions