panic!() (bare panic triggered by ErrorLogger on Err in debu

Error message

panic!() (bare panic triggered by ErrorLogger on Err in debug builds)

What it means

The ErrorLogger implementation intentionally panics on any Err when Sniffnet is compiled with debug assertions (src/utils/error_logger.rs:21). The panic is gated by #[cfg(debug_assertions)] and #[allow(clippy::panic)], so every error that flows through log_err() during development aborts immediately with a bare panic!() (empty panic message) right after the 'Sniffnet error at [...]' stderr line. This is a fail-fast developer aid: in release builds the same code only logs and continues.

Source

Thrown at src/utils/error_logger.rs:21

/// Trait for logging errors in a unified way
pub trait ErrorLogger<T, E> {
    /// Log the error and its location
    #[allow(clippy::missing_errors_doc)]
    fn log_err(self, loc: Location) -> Result<T, E>;
}

impl<T, E: Display> ErrorLogger<T, E> for Result<T, E> {
    #[allow(clippy::print_stderr)]
    fn log_err(self, location: Location) -> Result<T, E> {
        if let Err(e) = &self {
            let file = location.file;
            let line = location.line;
            eprintln!("Sniffnet error at [{file}:{line}]: {e}");
            // in debug mode, panic on error
            #[cfg(debug_assertions)]
            #[allow(clippy::panic)]
            {
                panic!();
            }
        }

        self
    }
}

/// Struct to store the location in the code (file and line)
pub struct Location {
    pub file: &'static str,
    pub line: u32,
}

#[macro_export]
/// Macro to get the current location in the code (file and line)
macro_rules! location {
    () => {
        Location {

View on GitHub (pinned to 48b0575dc0)

Solutions

Look at the last stderr line before the panic ('Sniffnet error at [file:line]: <error>') — that is the actual failure; the panic is just the debug-mode amplifier.
Fix the underlying error (permissions, missing device/file, invalid path) identified by that line.
Run `cargo run --release` (or a packaged build) when you need the app to continue past recoverable errors.
Run with `RUST_BACKTRACE=1` to confirm which log_err call site panicked.
As a last resort for local debugging only, temporarily remove the #[cfg(debug_assertions)] panic block — do not ship that change.

Example fix

// before — debug builds panic on every logged error
if let Err(e) = &self {
    eprintln!("Sniffnet error at [{file}:{line}]: {e}");
    #[cfg(debug_assertions)]
    {
        panic!();
    }
}

// after — fail fast with context instead of a bare, message-less panic
#[cfg(debug_assertions)]
{
    panic!("Sniffnet error at [{file}:{line}]: {e}");
}

Defensive patterns

Strategy: try-catch

Try / catch

// You cannot catch this panic portably (no catch_unwind around log_err in app code);
// instead prevent the Err from reaching log_err in debug runs:
#[cfg(debug_assertions)]
if risky_capture_op().is_err() {
    eprintln!("capture setup failed; run with privileges or pick another device");
    return;
}
risky_capture_op().log_err(crate::location!());

Prevention

Never assume a bare panic in a debug run is a real bug — check the preceding 'Sniffnet error at' stderr line for the cause.
Run with RUST_BACKTRACE=1 to map the panic to its log_err call site.
Use `cargo run --release` when you need tolerant behavior during manual testing.
Give the dev binary capture privileges (setcap/sudo) so log_err sites don't fire at all.

When it happens

Trigger: Any `.log_err(crate::location!())` call site returning Err while running a debug build: `cargo run`, `cargo run -- --restore-default`, `cargo test` exercising CLI paths (src/cli/mod.rs:45,47,57), or pausing a live capture (capture_context.rs:158). Because the panic message is empty, the only context is the stderr line printed just before the panic and the resulting backtrace.

Common situations: Developers running the app via `cargo run` without elevated privileges, so pcap open fails and log_err panics; CI test jobs compiled in debug mode that touch filesystem or capture code paths; contributors confused by a panic with no message — the real cause is always the preceding 'Sniffnet error at [file:line]: e' line.

Related errors

AI-assisted analysis of GyulyVGC/sniffnet@48b0575dc0 (2026-08-16). Data as JSON: /api/errors/5398d53ed9d24215. Report an issue: GitHub.