[ros-kernel] Enhanced error messages

[Mark Weaver]

> Hello,
> 
> wouldn't you all sometimes wish to see a more descriptive error message
> like "File 'c:\path\to\file.txt" could not be found." instead of just that
> "File not found." message?
> 
> We can implement this hidden in the OS without breaking any API.
> What we need is just to extend CreateFile() and FormatMessage().
> If CreateFile() can't find what it was searching for, it calls a new
> function SetLastErrorWithInfo(ERROR_FIND_NOT_FOUND, path)
> instead of only SetLastError(ERROR_FIND_NOT_FOUND).
> The string is stored like the last error code as per-thread info.
> FormatMessage can then look if there is additional information
> and include in the formatted message.
> 
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.  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 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 thread.  Alternately, it implies allocating memory at each failure, which is more weight again.

> 
> What do you think?
>
In short, it's not possible to implement 100% correctly (although you could cover most cases) -- and has a cost for every thread.  Not a bad idea in principle, but sadly given the design constraints something that should be left up to the application.

Mark