4.3 Error reporting from the Facade

This page is part of the ING document INS-DAS-31 Design notes for UltraDAS

Reports from the Facade itself; ERS

The Camera-facade uses the ING component srvTalk to connect to the system log via syslogd. This is now a common mechanism among ING's server programmes. The srvTalk module is initialised from the Camera_facade::new_facade (i.e. from the constructor) and establishes two routes into syslog.

The srvTalk function sends a message directly to the system log.
The ERS functions of DRAMA are subverted and calls that flush the ERS table now send messages direct to syslog if (a) the messages have the ERS_M_BROADCAST flag set or (b) there is no client programme associated with the context in which the table is flushed. If neither a or b apply, then the messages are sent to the client programme as is normal in DRAMA.

To make the second mechanism work, srvTalkInit is called from Camera_facade::new_facadeafter DitsAppInit; if the order was reversed, DitsAppInit would cause all messages to go either to the client or to the terminal window from which udas_camera was started.

Any error messages reported from DRAMA libraries will leave the Facade by one of these two routes.

Reports through the Facade: talk_to_facade

Any object that uses the Facade (that's most objects in the programme) can call talk_to_facade to send a message to the system log. The message goes directly to the log and is never sent via the client of an action. The sending object must specify the urgency of the message, which determines where the message is logged and displayed. See the Facade class prologues for details.

Reports to the Facade; Exceptions from actions

Actions that fail return Exception obejects to the Facade. The Facade cannot forward these objects outside udas_camera as they are meaningless outside the DAS and cannot pass across the DRAMA message net. Therefore, the Facade accepts the exception, by calling the accept_exception method, which causes the text of the Exception to be passed out through the Facade in a series of calls to talk_to_facade. Before this call, which destroys the Exception, the Facade extracts the Exception's condition code and stores it for later use as the final status of the action.