Don't panic

[Henrik Böving]

We should never panic, instead always return Result's and try not to unwrap unless we can be absolutely sure it is safe.

[Femi Bankole]

Hi @elpiel, there are only three panic!s in the codebase, all of which are part of the tests for the file_log_parser.

1. nmea/tests/file_log_parser/mod.rs

   Lines 14 to 15 in 931a615

    let res = process_file(&Path::new("tests").join("data").join("nmea1.log")) 
        .unwrap_or_else(|err| panic!("process file failed with error '{}'", err)); 

2. nmea/tests/file_log_parser/mod.rs

   Lines 75 to 84 in 931a615

    macro_rules! err_handler { 
        () => { 
            |err| { 
                panic!( 
                    "Parsing of {line} at {log_path:?}:{line_no} failed: {err}", 
                    line_no = line_no + 1 
                ) 
            } 
        }; 
    } 

3. nmea/tests/file_log_parser/mod.rs

   Line 181 in 931a615

    _ => panic!("You need to add sat state for new log here"), 

Is there a need to remove these ones?

[Lachezar Lechev]

Hello @iTranscend thanks for taking a look at this!
It's not needed to fix these places in the tests.

Apart from panic! macro calls, however, there are other methods that also panic on error. For example, Option and Result both have expect (if you know it's impossible to fail and you want to add a message to it), expect_err (mostly used for testing), unwrap and unwrap_err.
There are more methods which do not panic but instead do something with the missing field (None) or failing check (Err).

Could you please take a look for unwrap & expect too in the code?

[Lachezar Lechev]

I've also encountered a few unreachable! calls which should be best handled by an Error in case of bad data passed as a valid sentence for these fields.

Ideally, we should communicate the field name and the passed data which has triggered this error and eventually include e.g. valid options or even better - a message containing either the possible options or the expected data.