[ros-kernel] Re: Enhanced error messages

[Mark Weaver]

> 
> 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().
> 
Not true.  It's entirely reasonable to call GetLastError(), save the result, and then perform other processing before calling FormatMessage.  You don't lose any information that way.

> >  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.
That's not a design flaw, it's the way the API works.  FormatMessage can fail, like any other API function, and needs to report errors when it does.

> > 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.
> 
It's more than just a pointer: you have to store potentially a number of previous errors (to work around other API calls inbetween the error occurring and FormatMessage) _and_ the filename/object path associated with each one.  You can't just store a pointer to the user's filename buffer as this may not be valid by the time you get around formatting the message.  In particular, this is likely to be the case for the kind of application that is lazy about its error reporting.