Follow-up to this comment:
Currently we use io::Result in most places. These errors are not user-friendly, because they lose context about the file that we had a problem with (if it’s a file at all).
Also, all propagated errors get “handled” in main like so:
|
Some("send") if args.len() >= 3 => { |
|
let addr = &args[1]; |
|
let fnames = &args[2..]; |
|
main_send(addr, fnames).expect("Failed to send."); |
|
} |
|
Some("recv") if args.len() == 3 => { |
|
let addr = &args[1]; |
|
let n_conn = &args[2]; |
|
main_recv(addr, n_conn).expect("Failed to receive."); |
|
} |
I think it’s okay to crash the application in case of an IO error — I don’t think we need to be robust against transient failures, the user can just restart the transfer instead — but we can report clearly what went wrong and where.
Follow-up to this comment:
Currently we use
io::Resultin most places. These errors are not user-friendly, because they lose context about the file that we had a problem with (if it’s a file at all).Also, all propagated errors get “handled” in
mainlike so:fastsync/src/main.rs
Lines 82 to 91 in cfba4cc
I think it’s okay to crash the application in case of an IO error — I don’t think we need to be robust against transient failures, the user can just restart the transfer instead — but we can report clearly what went wrong and where.