Hi,
I'm looking for advice or a standard pattern for passing errors from my internal program accesed through a dll to labview.
My dll creates a new thread for interprocess communication and is communicated with by further dll calls. There's two sources of error in this program: One, when the user calls a dll method (vi) using bad parameters, wrong state etc. in which case the dll call simply returns an error. Second, errors generated internally by the thread which is logged (with a line number prefixed) to a circular (string) buffer array and passed back upon request by a dll call.
The problem is that for case one I sometimes need to pass back more info than an integer, such as a windows error code etc. So for case one, for some (specified) dll functions I allow it to log to the buffer of case two and then simply return the line number. So now I have multiple ways, depending on the vi for logging/getting errors. But this is a bit cumborsome because it implies that returning vi might have took up the error by the line number in some internally stored (probably) USR. But I don't want to convert all of the functions to return strings.
I realize that a central question that I should ask myself is for whom are this errors meant to to be useful. It's for the developer that uses this library because they'd have to do some configuration to get it to work properly, Example errors are out of memory error, process not found, timed out comm, and mostly if the internal packets sent between the process are unrecognized. Then (if selecetd by user) non-errors but simply info is added to the log to help the developer understand what's happening internally.
I cannot log only error numbers which would be looked up in a pregenrated string table to get the description because as described some error descriptions are generated during runtime. For example, the followng is some error that might be generated:
CString csTemp;
csTemp.Format("2;%d;;Unknown command received, code %d (0x%08X), param1 %d", TKE_BAD_PACKET, pPkt->nCode, pPkt->nCode, pPkt->nParam1);
For a developer it might indicate that they forgot to call some vi. But when it gets to the user, I expect that only an error code would suffice, but the developer would have to transiltae these errors into simple things that the user can do.
So what is your error logging philosphy when you need to return errors to help a developer debug? Do you have any suggestions for this situation or do you think my solution looks good.
I'd broaden out the question, do you ever handle errors or just pass them on to the user with the error handler vi? I'm still trying to make up my mind if errors such as out of memory or timed out errors are evry useful, I mean what is the user ever going to be able to do about this? But I have to let someone know that something is going wrong, shouldn't I?
Kind regards,
Matt
