I see, maybe i’m still not familiar with it. I’ll explore more about error handling in rust later.

Thank you for the pointer.

For the crates, basically its a wrapper i presume? To remove the boiler plate right?

Hello and Thank You :D Rust really intrigues me so i really want to explore more about Rust

cargo clippy I’ll look for Clippy

These comments should be doc-comments (///) so that cargo doc picks them up. I see, i guess i skimmed the Rust Docs :D

but in general you might be interested in crates thiserror and anyhow that simplify error handling. Still, Rust Error Handling and Rust in General is still a big black box for me yet to be unveiled :D, why do i need crates for error handling? But I’ll look into it. Still can’t quite grasp the concept of Rust

Duration::from_mins(1) would be much more readable. Nice info, never knew this existed before, because i found it in some tutorial that timeout need something in Duration.

You should almost never panic. Your function already returns a Result<>, so you should be using that for error handling. Still figuring how to handle error, but just like what the others say, panic should never occurred, and always return the error

Not Rust specific, but usually I recommend to handle errors first, and return from the function early. This way you reduce cognitive load on the reader, and reduce nesting of if-blocks. That’s actually correct, thank you for your input, i always ended with nasty nested if before because of this. Never thought about it before XD

Thank you for your input. I’ll refactor my code

To Panic or not to Panic Thank you for your pointer. I just remember this from the docs. So basically, the general rule is only to use panic when something bad really happened, and my program cannot continue right? otherwise always return the error?

Really panics should only be used when the situation should never occur and if it does that indicates a bug in the program

I’ll rethink the use of panic in my code

would this section suffice? https://doc.rust-lang.org/book/ch09-00-error-handling.html

First, you should almost never take in a &String as a function argument. This basically means you have a reference to a owned object. It forces an allocation of everything passed into the function only to take a reference of it. It excludes types that are simply &strs forcing the caller to convert them to a full String - which involves an allocation. The function should just taking in a &str as it is cheap to convert a String to a &str (cheaper to use than a &String as well as &String have a double redirection).

I think i need to explore more about pointer and reference? its still a new concept for me :D, so i just throw everything with &String without a strong understanding about the things it does in the background. Thank you for pointing that out.

Second. String/&str are not the write types for paths. Those would be PathBuf and &Path which both work like String and &str (so all the above applies to these as well). These are generally better to use as paths in most OSs dont have to be unicode. Which means there are files (though very rarely) which cannot be represented as a String. This is why File::open takes in a AsRef<Path> which your function can also.

What i learned from this is that a misconception of the parameter input. Instead of using String, i have to treat it as PathBuf?, I’ll check it out later

Lastly. I would not conflate opening a file with parsing it. These should be two different functions. This makes the code a bit more flexible - you can get the file to parse from other sources. One big advantage to this would be for testing where you can just have the test data as strings in the test. It also makes the returned error type simpler as one function can deal with io errors and the other with parsing errors. And in this case you can just parse the file directly from the internet request rather than saving it to a file first (though there are other reasons you may or may not want to do this).

I do agree with this statement, I’ll refactor my code to seperate the read and the parse logic

Thank you Nous.

PS: How do we tag other users? XD

Box<str> instead of String

I need to explore more about this. I really have no idea about this

Your parsing code looks both unrobust (potentially fragile hard-coded assumptions) and unnecessarily complex. Something much simpler can probably be done with some trivial regex usage.

My first approach is using regex, but it seems like overkill? because the data from https://standards-oui.ieee.org/oui/oui.txt is somehow already structured.

But i’ll try the regex approach later.

Thank you :D

This is a IMO horribly hangup from languages that require you to declare something before you can use it. You don’t need to do that in rust. So put your functions in order that makes sense to read them from top to bottom.

Hello, nous.

Thank you for your feedback. I just know today that in rust, you can do this. I do agree with you about how to order things so it can convey more meaning to the reader. I’ll keep that in mind in my next iterations.

Thank you