Inevitably, a data file will fail to load or save properly, especially during the I.F. development process.  BARfly reports detailed information about the conditions leading up to the failure as plain text.  Choose Information.Show Load/Save Failures from the menu to display failure information.

There are two pieces of information pertinent to failure info:  the call stack and the node record.  The information is essentially the same as that reported by the BAR::Get_Failure_Call_Stack and BAR::Get_Failure_Node_Record interfacial functions.

The call stack is a record of the functions being called at time of failure, displayed backwards from function where error occurred to function that started a function execution session.  Construct scope, function name, and failure location are reported for each function call.  Note that not all failures during loading and saving will involve the call stack, since some failures, especially validation failures, come about from the entire file being invalid, rather than a particular point in a function having a specific problem.

The node record is a sort of "walkthrough" of the deserialization or serialization procedures at the time the failure occurred, working backwards from approximate procedure failure point to top-level block mapping and preparation.  This record is not foolproof, especially for validation failures, since it is unclear from the perspective of BAR which failures are "intended" and which ones are "unintended."  Construct name, relative child position, and construct size are reported for each step of the procedure.

BAR takes safety in file deserialization and serialization very seriously. Many binary loading or saving algorithms can cause exceptions, deadlocks, and program crashes if invalid content is encountered. BAR's universal mechanism for deserialization and serialization generally only results in either a BAR critical error or a validation failure, neither which cause BARfly (or any other application using the BAR engine) to crash.

BAR's failure-reporting capability provides a significant advantage over general-purpose binary loading and saving algorithms.  It is difficult to write general-purpose code with so many possible "failure points" handled seamlessly; BAR not only catches all faults, but remembers what it was doing at the time of failure.

  See also: [Viewing node information] [Viewing the log] [Viewing memory blocks]
[Viewing file information] [Construct hierarchy diagrams] [Determining I.F. protocol support]