Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Error Handling in Applications

Error handling is critical aspect of developing applications in any programming language. Error handling is a mechanism where applications can notify error conditions to end users. A-Stack is a collection of number of atomic domain languages, the error handling varies based on language the application is using. Error handling in A-Stack can be classified into three broad categories -

  • Error handling in NewFacetInstances
  • Error handling as part of process code in non-workflow definition language.
  • Error handling in Workflow Definition Language

Trapping Errors in NewFacetInstances

A-Stack provides <OnError> event as part of Facet life-cycle which can be used 

Trapping Errors in Queries

A-Stack Error handling mechanism can be used to trap errors 


To Configure broadcast of message:

Broadcast Log Messages Configuration
<Query>
  <SetLocalData key="ErrorHandler">
    <Value>
      <SetResponseData>
        <Key>
          Message.Value.Error
        </Key>
        <Value>
          [:$Error:]
        </Value>
      </SetResponseData>
    </Value>
  </SetLocalData>
  <Find Format="Version">
    <VendorInfo1>
      <vendorId>
        <NE>
        </NE>
      </vendorId>
    </VendorInfo1>
  </Find>
</Query>

Explanation

  • sff.log.broadcast.<log level name> which defines one or more facet IDs used for log broadcasting. That is:
    •  <sff.log.broadcast.error>[:MyErrorsFacet:]</sff.log.broadcast.error> - This one will broadcast log error messages to [randomized] [:MyErrorsFacet:] fid 
    • <sff.log.broadcast.all>wstest</sff.log.broadcast.all> - This one will log messages to wstest fid.
      You can specify more than one fid as comma-separated list.
    • Known Log levels are: 
      1. text
      2. trace
      3. debug
      4. info
      5. warn
      6. error
      7. fatal
      8. all

  • sff.log.broadcast.protocol. Default value is “ws,wss”. This is the list of protocols which will be used to select broadcast pipelines. That is, it will *not* broadcast on HTTP connections, for example. When broadcast is enabled, startup will log the list of protocols so you know it was enabled. Obviously, it will *not* print the list of facet IDs used for broadcast.

  • sff.log.broadcast.message. This is log message definition. It may come in different forms:

    • <sff.log.broadcast.message>json<sff.log.broadcast.message> This simplest form allows you to define log message type (e.g. xml or json). Default is xml.

  • Default message in JSON format will look like this:

    Default Message
    {
  "Log":
  {
    "Level":"WARN",
    "Source":"SffSequenceFacet",
    "Timestamp":1479334740055,
    "Message":"startSchedularForMonitorStatus:MonitorStatus 1:0 @ Wed Nov 16 14:19:00 PST 2016: Scheduled: skip past (-55 ms) event for Wed Nov 16 14:19:00 PST 2016 [0../30sec]"
  }
}

    In XML Format:

    Default Message
    <Log>
  <Level>WARN</Level>
  <Source>SffSequenceFacet</Source>
  <Timestamp>1479334740055<Timestamp>
  <Message>startSchedularForMonitorStatus:MonitorStatus 1:0 @ Wed Nov 16 14:19:00 PST 2016: Scheduled: skip past (-55 ms) event for Wed Nov 16 14:19:00 PST 2016 [0../30sec]</Message>
</Log>


    Log messages are automatically added to the logger window on TQLConsole



  • No labels