[QOP] Results should be used where errors "unwraps" or panics can occur.

[john-bv]

Issue / Question:
Currently, we do not use results, and as a result, a simple function such as u32::compose(&[0, 0, 0, 1], &mut 0) may panic, and kill the main thread. We expect a possible error here therefore it should NOT terminate the main thread, but rather just error in console, with a description of what happened.

Proposals / Details:
In places where an unwrap or any function that has the potential to voluntarily panic we should be using results. Consider the following potentially erroneous code:

fn do_read(some_bytes: &[u8]) -> String {
    // read the first byte (length) of the string.
    let length = some_bytes[0];
    // now read for length
    let contents = &some_bytes(1..length);
    String::from_utf8(contents).unwrap()
}

This proposal would change the potentially erroneous code above to:

fn do_read(some_bytes: &[u8]) -> Result<String, ErrorEnum> {
    // read the first byte (length) of the string.
    let length = some_bytes[0]?;
    // now read for length
    let contents = &some_bytes(1..length);
    String::from_utf8(contents)?
}

[john-bv]

@buchwasa I'm kind of curious how relevant you think this is, also how do you think the ErrorEnum should look?

[john-bv]

While write operations should never fail, i'm still implementing them, (for now) on the proposal.

However this will be mandatory for read methods where operations have higher potential to fail.

[john-bv]

This issue has been marked complete by the following commits:

• NetrexMC/RakNet@5b82d5a
• NetrexMC/binary-utils@0f34ea9
• NetrexMC/Protocol@1918d56