[ros-kernel] Re: Enhanced error messages

[Royce Mitchell III]

We could create a small circular list to store a history of the last 4
errors this particular process encountered, and the extended
information associated with it. Then, there could be an app that would
allow the user to select the process and query it's error history.

Or... we could write a util similar to Sysinternals that would capture
the new information, including the process, so if a user is having a
problem, they could fire up this util and try again.

3rd, we could have an option in the OS to send system DEBUG or TRACE
messages whenever an error occurs, and there can be one of (at least)
two ways to turn this on:

  1) a registry entry that turns it on for all processes.

  2) a bit in the process-specific data enabling this feature for that
     particular process.

As has been stated, most well-written applications will report the
offending failed file name, anyways, so this is something that would
only be needed for those situations where you're not getting the file
name.

Just my lame 2c.

Saturday, January 10, 2004, 9:18:51 PM, you wrote:

>> 
>> 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.


> _______________________________________________
> Ros-kernel mailing list
> Ros-kernel at reactos.com
> http://reactos.com/mailman/listinfo/ros-kernel
 



--
May you always find water and shade,
 Royce
---------------------