tag:blogger.com,1999:blog-6628985022531866193.post3410774964407904515..comments2024-02-12T17:37:05.629+00:00Comments on The OldWood Thing: Diagnostic & Support User InterfacesChris Oldwoodhttp://www.blogger.com/profile/18183909440298909448noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-6628985022531866193.post-58676764814026265942012-01-17T23:02:58.405+00:002012-01-17T23:02:58.405+00:00An interesting insight on a real cost and quality ...An interesting insight on a real cost and quality issue. <br /><br />I guess exception and error logging needs better planning and design from the outset. It often gets 'beefed up' when issues emerge during the development process.<br /><br />Perhaps formally incorporating this aspect into testing would be the 'sanity check' that could avoid the 'Valuing trade ... and 'Failed to correlate pairs' type of gaffes. Or at least some code review of trace during development?<br /><br />It might be achieved if the developers had a range of functions designed to anticipate and handle the applications error and warning conditions. An abstraction layer of some sort would provide more flexibility in tweaking the actual mechanics and semantics of the logging etc.<br /><br />Maybe a formal approach would be too rigid and a moving target in any case, perhaps a more generic XML approach to logging would allow enough information to be logged using something like an XDocument object which would allow later analysis to use Linq to XML querying to the degree of focus required (assuming a .NET platform). The API approach could be substituted with formal guidance and a dictionary of well known property types to log by convention.<br /><br />Of course once this type of standard is in place across the organisation, a GUI to help view and interrogate the output would be a good investment and interesting to develop. Presumably by your department!Lloyd Franklinhttps://www.blogger.com/profile/08694300956065972432noreply@blogger.com