[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