Logging#

Do not rely on std::cout for extension diagnostics.

In the user version of SAMSON there is no regular developer console, so plain standard output is not a reliable way to surface messages. Instead, SAMSON provides logging macros that attach context such as file, function, line, and extension identity.

Tip

If your extension, or a library/executable used in it, use std::cout, std::cerr, qDebug(), qWarning(), then you or the user can see these messages via the Log Viewer extension.

Main logging macros#

The most common macros are:

SB_INFORMATION
SB_WARNING
SB_ERROR

These messages are routed to the console or the log file through SAMSON's logging system. You can see the log via the Interface > Show log.

When to use each level#

Use SB_INFORMATION for useful runtime information during development or for notable non-problem events.
Use SB_WARNING when something unexpected happened but the extension can continue safely.
Use SB_ERROR when an operation failed or the state is invalid.

Because the log level controls which messages are emitted, information and trace-style output should remain meaningful rather than noisy.

Why the macros matter#

The logging macros include location metadata automatically. That makes them much more useful than ad hoc print statements when debugging extension behavior across many source files.

They also integrate with SAMSON's own logging manager, so they remain visible in the environments where users and developers actually run the software.

Example#

if (!resultIsValid) {
    SB_ERROR("Failed to compute the custom interaction model parameters");
    return;
}

SB_INFORMATION("Custom interaction model initialized");

Practical advice#

Use logging for diagnostics, not for user-facing workflow messaging.
Keep messages specific enough to identify the failed step.
Prefer one useful error over many repetitive low-signal messages.