[ros-kernel] Re: Enhanced error messages
Martin Fuchs
martin-fuchs at gmx.net
Thu Jan 8 10:29:26 CET 2004
> This of course assumes that you haven't called another error setting API
> function (i.e. nearly all of them) in-between CreateFile and FormatMessage
> that would destroy that information. In a lot of cases, that's not
> necessarily true. Consider the common code path trap error->cleanup->report
> error. If any API calls are involved in the cleanup, or pre-report phase,
> then the extended error information would be lost. This could even be heap
> allocation in some cases.
This problems could been dealed with. A reasonable library avoids to destroy
error information in the error path. It it does not, it also destroys the error
code of GetLastError().
> The other case that breaks is calling
> FormatMessage with no buffer, to get the number of characters required for
> it (then typically followed by storage allocation). Not 100% sure, but it's
> a fine bet that GetLastError() == ERROR_INSUFFICIENT_BUFFER after that,
> which again would destroy the extended information. In addition, you have
This would be a design flaw in FormatMessage() itself. Could also be dealed
with since we write out own version.
> to consider where the storage for this information is coming from --
> seemingly it would have to be some TLS as the last error number itself is,
> and that implies extra weight per thr!
> ead. Alternately, it implies allocating memory at each failure, which is
> more weight again.
It's just one pointer more per thread, and a string copy in case of some errors.
I think this won't hurt compared to the gain of better error messages.
More information about the Ros-kernel
mailing list