RE: Re Debug messages

[Patrick Lidstone \(Personal E-mail\)]

>
> I was thinking in terms of something significant has occured,
> an application error, some kind of device error, anything you like.
>
> The details of this may be well beyond the scope of a simple
> debug/error/logging xAP message, but might be saved to a file
> for later analysis e.g. a call stack dump.

A couple of thoughts:

1) Include an error number. Ideally we need to ensure these are unique
(perhaps by combining with the vendor ID).

2) Distinguish between technical errors (bugs) and application errors
(stuff that didn't work out right, or couldn't be complete). For
example, a technical error might be the result of a null pointer being
detected somewhere where it wasn't expected. An application error might
result from failure to validate a particular message targeted at a
device, or, say, failure of a local lookup for a scanned barcode or
similar.

This is really exception handling rather than debugging per-se.

> Given an error from a particular application, it may want to
> store its information in a particular file, perhaps named
> after the date/time/event so lots of files are created over time.
>
> The log file may or may not be retrievable remotely, but if
> something occurred that I'm interested in I might wish to go
> look into it later on, and knowing the file to look into for
> that error might be useful.
>
> Just a thought, I'm easy either way,

Bit PC-centric (well, Windows centric), but I spose it might be useful
one day?

P.