DEV Community: nikhilraojl

Taking an input and printing stuff in rust

nikhilraojl — Sun, 01 Oct 2023 06:43:12 +0000

In python taking input from the user is as simple as using the built-in input function, assigning it to a variable and using it as we need. Below is a simple program which takes in a name from a user and prints out a greeting

name = input("Please enter your name: ")
print(f"Hello {name}")

# Output:
# Enter your name: John Smith
# Hello John Smith

In rust, and in many low level languages, to capture a user input we first have to read from stdin and store it in a buffer which can then be used as needed. Let's see how this looks all put together

A small note on stdin, stdout, stderr

In a nutshell

stdin -> Standard Input, your process reads information from you

stdout -> Standard Output, your process writes normal output

stderr -> Standard Output, your process writes debug output for more detailed information read the wikipedia page on this topic StandardStreams

Let's get back to our rust program

fn main() {
    // Prints to the standard output, with a newline.
    println!("Please enter your name: ");

    // create an empty buffer before hand
    let mut name_buf = String::new();
    // create a `Stdin` object
    let stdin_handle = std::io::stdin();
    // read a line from stdin and store it in buffer `name_buf`
    stdin_handle.read_line(&mut name_buf).unwrap();

    println!("hello {}", name_buf);
}

// Output:
// Enter your name:
// John Smith
// hello John Smith

NOTE: I am going to use unwrap instead of handling errors to have less things to worry about

If we look closely there is a small difference in the two programs. In python the prompt and name input both happen on same line but in our rust program the input happens on a new line

RUST
Enter your name:
John Smith  <- input on a new line
hello John Smith

PYTHON
Enter your name: John Smith <- input the same line
Hello John Smith

What if we want the similar behaviour in rust? We some how need to avoid printing a new line after the prompt. For this we can use print! macro for this. Reading the print! docs ...

Prints to the standard output.

Equivalent to the println! macro except that a newline is not printed at the end of the message.

Let's try this out

fn main() {
    // Prints to the standard output, without a newline.
    print!("Greetings, please enter your name: ");

    let mut name_buf = String::new();
    let stdin_handle = std::io::stdin();
    stdin_handle.read_line(&mut name_buf).unwrap();

    println!("hello {}", name_buf);
}

// Output:
// John Smith
// Enter your name: hello John Smith

This output was not what we expected. But before understanding what's going on let's try something that fixes this and work our way backwards. Let's try std::io::stdout().flush().unwrap() from one of the examples in the docs

// flush method comes from `Write` trait. We need this in scope
use std::io::Write;

fn main() {
    print!("Enter your name: ");
    // immediately "push"(flush) buffer to stdout
    std::io::stdout().flush().unwrap();
    let mut buf = String::new();
    std::io::stdin().read_line(&mut buf).unwrap();
    println!("hello {buf}");
}

// Output:
// Enter your name: John Smith
// hello John Smith

Yay, we go the output we wanted. The reason for earlier "bad" output was that stdout is usually line buffered i.e once there is a new line character in the buffer, the buffer will then immediately be flushed/printed to stdout. Taking output from first print! program above analyzing

-----PROGRAM STARTS-----

John Smith
^--- input prompt in buffer is not flushed until we type name and hit enter(newline) key

Enter your name: hello John Smith
^--- prompt and  ^--- greeting are flushed to stdout together causing "bad" output

-----PROGRAM ENDS-----

To avoid such issues we can use std::io::stdio().flush() as needed to push data to stdout immediately.

One more difference between `print!` & `println!`

Another difference between print! and println! is that the print! doesn't accept empty args but you can call println! without any args

// Program 1
fn main() {
    println!();
    println!("Hello World");
}

// Output:
//                <- empty line
// Hello World

// Program 2
fn main() {
    print!(); // <- this will fail to compile
    print!("hello World");
}

// Output:
// error: requires at least a format string argument

To find out we can look at source of print! & println! macros

macro_rules! print {
    ($($arg:tt)*) => {{
        $crate::io::_print($crate::format_args!($($arg)*));
    }};
}

macro_rules! println {
    () => {
        $crate::print!("\n")
    };
    ($($arg:tt)*) => {{
        $crate::io::_print($crate::format_args_nl!($($arg)*));
    }};
}

Looking at the source we find that if there are no args passed to println! we simply print a new line using, print! macro. But such is not the case for print! macro, we have to pass in some arguments or it won't compile.

Hopefully you understand a couple of differences between print! and println!. Now diving a little deeper

Diving deeper

If stdout is line buffered then it is a good guess that there must be a size limit to that buffer. Let's try to find its true and try to find the limit

Note: I am doing this on a 64 bit windows machine with 1.72 rustc. Findings may be different on different machines. This may not be the right way, I am just having fun tinkering and sharing what I found

fn main() {
    let array = [1; 500];
    print!("{array:?}");
    let mut buf = String::new();
    std::io::stdin().read_line(&mut buf).unwrap();
    println!("hello {buf}");
}

// Output:
// [1, 1, 1, 1, 1 ..(repeated around 336 times) JohnSmith
                                            //  ^ input
// ...(remaining) 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]hello JohnSmith
                                            // ^ output

When we try to print out an array of 1s of length 500, we see some of them are printed before taking input and some after. We can then make a guess, the first portion of 1s might have been written out as it exceeded the buffer limit and remaining output stays in buffer until flushed later. We can try to test this hypothesis by increasing size of array from 500 -> 700. You can try this for yourself, you should see that the first output portion of array is doubled.

// Output:
// [1, 1, 1, 1, 1 ..(repeated around 660 times) JohnSmith
                                            //  ^ input
// ...(remaining) 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]hello JohnSmith
                                            // ^ output

Getting a little side tracked on formatter

There was a small thing that was irking me in the above example. Why only 341 1's are printed. It must be that the debug format adding brackets, spaces and commas adding to buffer size. Okay, now on to finding the size of the debug printed array

#![feature(fmt_internals)]

use std::fmt::{Formatter, Debug};

fn main() {
    let arr_341 =  [1; 341];
    let mut fmt_buf = String::new();
    let mut fmtr = Formatter::new(&mut fmt_buf);
    arr_341.fmt(&mut fmtr).unwrap();
    println!("BUF SIZE: {}", std::mem::size_of_val(&*fmt_buf));
}

// Output:
// BUF SIZE: 1023

There is a little more going on here than some of the earlier examples. Going from top to down

#![feature(fmt_internals)] -> this is a flag that allows the use of constructing Formatter object as fmt_internals is a unstable feature and shouldn't be used in normal code. Also this requires rust nightly
fmt_buf -> is an owned string
Formatter::new() -> constructs a new formatter object with the passed in buffer
std::mem::size_of_val() -> gives us the size of an object through shared reference
&*fmt_buf -> we have to dereference first because &fmt_buf is a &String fat pointer with size 24 bytes(address, length, capacity) and we want the size of what the pointer is pointing to and not the size of pointer itself. *fmt_buf is a str object and we can pass a refernce(&*fmt_buf) to this object to size_of_val function to get the correct size

Now if I increase the length of array from 341 to 342, first the size of the debug format buffer becomes 1026 and intitally 1024 are printed out and then the remaining 2 bytes. Try the below program to verify it yourself

#![feature(fmt_internals)]

use std::{fmt::{Formatter, Debug}, time::Duration};

fn main() {
    let arr_342 =  [1; 342];
    let mut fmt_buf = String::new();
    let mut fmtr = Formatter::new(&mut fmt_buf);
    arr_342.fmt(&mut fmtr).unwrap();
    print!("{arr_342:?}");

    std::thread::sleep(Duration::from_millis(5000));
    println!();
    println!("BUF {}", std::mem::size_of_val(&*fmt_buf));
}

// Output:
// [1, 1, 1, ...(repeated until 1024 bytes) |sleep 5sec| 1]
//                                                       ^^The last 2 bytes  are printed after the 5sec sleep.

Sucker punch on our expectation

The theory so far is that the usual buffer size while writing to stdout is 1024 bytes and anything less will not be flushed immediately. Testing on an array supports this theory. Now on to try on different data structures. Let's try a String with the size of 1000 bytes or something less than our guessed size limit for output buffer

use std::{thread::sleep, time::Duration};

fn main() {
    let aa_string = "a".repeat(1000);
    print!("{aa_string}");


    sleep(Duration::from_millis(3000));

    println!();
    println!("STR SIZE: {}", std::mem::size_of_val(&*aa_string));
}

// Output:
// |Sleep for 3sec|aa... (repeated 1000 times)
// STR SIZE: 1000

As expected, the program sleeps first as the buffer is not exceeding the limit. Now let's try it with something that exceeds the 1024 bytes

// same as prev fuc except this line
    let aa_string = "a".repeat(1224);
//

// Output:
// aa... (repeated 1225 times)|Sleep for 3sec|
// STR SIZE: 1225

But this is not following our array example. According to our theory we should get the first 1024 bytes, sleep for 3 seconds, get remaining 200 bytes, then STR SIZE output. This example shows there is something more than just fixed buffer size for outputting stuff to stdout.

Unfortunately, this is as far as I got for now. I will dig into this topic more and will write another blog if I find something. In the mean time if any of you people reading this have more information kindly point me to those resources. I will be very grateful.

Whew, that's a long story on print! & println! . I had fun learning and experimenting about these things and hopefully you found some of it interesting. Thanks for reading and until next one

Intro to errors in Rust

nikhilraojl — Sat, 24 Jun 2023 13:51:37 +0000

Rust unlike many other programming languages doesn't have exceptions to handle errors. What does it mean by handling an error? Let's consider a very simple program in Python that converts a string into an integer with one success case and one that can fail

Error handling in Python

num_str = "10"
parsed = int(num_str)
print("completed")

# output
10

The above conversion from string to an integer executes successfully

name_str = "john"
parsed = int(name_str)
print("completed")

# output
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: 'john'

The above conversion fails with a ValueError exception. If we observe output the print statement after the exception is not executed. An exception not handled properly will halt the program, imagine such a piece of code halting a production server and needing a restart. Below is an example with a try-except block in Python, the exception is handled gracefully and will not halt the program.

name_str = "john"
try:
    parsed = int(name_str)
except ValueError as e:
    print(e)
print("completed")

# output
invalid literal for int() with base 10: 'john'
completed

This way, in Python, we can catch exceptions. Once we catch them we can then convert them to a different exception, log the exception or just ignore it.

Error handling in Rust

Coming back to Rust, let's code up a similar string to an integer conversion program.

fn main() {
    let num_str: String = "10".to_owned();
    let _parsed_string: i32 = num_str.parse::<i32>().unwrap();
    println!("Completed");
}

TIP: You can try this directly on rust playground https://play.rust-lang.org and see the output for yourselves

Here, we are trying to parse a String into i32 type and the program executes successfully. We will get to why .unwrap() is needed later. For now, we just want the code to compile and the Rust compiler won't allow it if we don't at least use unwrap. Now, what happens if we try and run this program

fn main() {
    let num_str: String = "john".to_owned();
    let _parsed_string: i32= num_str.parse::<i32>().unwrap();
    println!("Completed");
}

# output
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ParseIntError { kind: InvalidDigit }', src/main.rs:3:47
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The program panics during execution with a ParseIntError as it doesn't know how to convert characters in john to an integer value. Fair enough, but how do we handle such errors gracefully and not panic?

The `Result` enum

If we take a look at the parse method on a String type, we see that the return type is a Result.

pub fn parse<F: FromStr>(&self) -> Result<F, F::Err> {
    ...
}

The Result is an enum with two variants

Ok(T) -> representing success and its value
Err(E) -> representing error with error value

Ok, but how does a Result enum help us in error handling? Simple, every time there is a Result type returned from a function we need to handle both its variants, be it success or error. The Rust compiler shouts at us if we don't(try it for yourself in the Rust playground). If it is a success, we continue with the value from Ok variant and if there is an error we can handle it with Err variant. Below is an example of handling the error by just printing out a message

use std::num::ParseIntError;

fn main() {
    let num_str: String = "john".to_owned();
    let parsed_result: Result<i32, ParseIntError> = num_str.parse::<i32>();
    match parsed_result {
        Ok(parsed_string) => println!("Successfully parsed {}", parsed_string),
        Err(_) => println!("There was an error parsing the input"),
    }
    println!("Completed");
}

# output
There was an error parsing the input
Completed

If we observe the output, ParseIntError is now successfully handled by our program and the rest of the code is executed as well without panicking. This is what we were aiming for

The `unwrap` method

So what is the unwrap thing mentioned earlier? If we again take a look at our first Rust example in this blog converting 10 into an integer,

    let _parsed_string: i32 = "10".to_owned().parse::<i32>().unwrap();

we did not use any match statement to handle the Result enum, instead, we used the unwrap method. Yet the code compiled and returned the output successfully.

If the output from a function after its execution is of the Ok(T) variant the value from type T is consumed and the program continues as expected. But if the output from a function is of the Err(E) variant the current function will panic.

If we take a look at our second code example,

    let _parsed_string: i32 = "john".to_owned().parse::<i32>().unwrap();

where we tried to parse the characters in "john" into an integer using unwrap and our program panicked.

Why do we use unwrap if the program can still panic? unwrap is used to quickly handle any Result types only thinking about valid/correct cases and ignoring handling errors. Although heavy use of unwrap is discouraged, it is very handy during development. We can always go back and handle Result types properly at a later stage.

The `?` operator

Imagine a case where we are calling a function that returns a Result but we don't want to handle its Err variant manually(matching and returning a new Err), instead, we would just like to forward the Err to the calling function.

Let's consider the below example where we try to parse all elements in a Vec and return its total sum to any function that calls parse_vec_and_sum.

use std::num::ParseIntError;

fn main() {
    let strings_vec: Vec<&str> = vec!("1", "2", "3");

    let parsed_result = parse_vec_and_sum(strings_vec);
    match parsed_result {
        Ok(parsed_string) => println!("Successfully parsed vec to {}", parsed_string),
        Err(_) => println!("There was an error parsing the input"),
    }
    println!("Completed");
}

fn parse_vec_and_sum(v: Vec<&str>) -> Result<i32, ParseIntError> {
    let mut sum: i32 = 0;
    for i in v {
        match parse_int(i.to_owned()) {
            Ok(parsed_integer) => {
                // If parsing is successful, we just add it to total sum
                sum += parsed_integer;
            },
            Err(e) => {
                // If there is an Error, return it immediately
                return Err(e);
            }
        };
    }
    return Ok(sum);
}

fn parse_int(str: String) -> Result<i32, ParseIntError> {
    let x = str.parse::<i32>();
    let value: i32;
    match x{
        Ok(v) => {value = v;},
        Err(e) => return Err(e)
    };
    // Let's assume, for simplicity, some processing on `value` is needed after `.parse`.
    // Otherwise we could have just returned value from `.prase`
    return Ok(value);
}

# output
Successfully parsed vec to 6
Completed

The above example works fine, but it is very verbose to write. For such operations, we can use the handy ? operator. This question mark operator will either consume the value if Ok(T) or it will propagate the error by returning Err(E) to the calling function. Let's rewrite the above program using the ? operator

use std::num::ParseIntError;

fn main()-> Result<(), ParseIntError> {
    let strings_vec: Vec<&str> = vec!("1", "2", "3");

    let parsed_string = parse_vec_and_sum(strings_vec)?; // operator used here
    println!("Successfully parsed vec to {}", parsed_string);
    println!("Completed");
    return Ok(());
}

fn parse_vec_and_sum(v: Vec<&str>) -> Result<i32, ParseIntError> {
    let mut sum: i32 = 0;
    for i in v {
        sum += parse_int(i.to_owned())?; // operator used here
    }
    return Ok(sum);
}

fn parse_int(str: String) -> Result<i32, ParseIntError> {
    let x = str.parse::<i32>()?; // operator used here
    // Let's assume, for simplicity, some processing on `value` is needed after `.parse`.
    // Otherwise we could have just returned value from `.prase` directly
    return Ok(x);
}

# output
Successfully parsed vec to 6
Completed

Now, let's change the vec to something which can cause an error

...
    let strings_vec: Vec<&str> = vec!("john", "2", "3");
...

# output
There was an error parsing the input
Completed

The error ParseIntError is propagated from parse_int -> parse_vec_and_sum -> main. This makes our program even less verbose and a breeze to write.

Please note, the above example is a bit drawn out, it can all be packed into a main function but it is deliberately split into multiple functions to explain error propagation

Closing words

So far we have looked at basic error handling in Rust. We have looked at

Result enum which can either be success Ok(T) or failure Err(E)
Using .unwrap to quickly handle Result types
Use of ? operator to propagate errors through the calling functions

There is a lot more to learn about errors in Rust. Take the above example using the ? operator, we are returning only one error type, what if multiple errors are returned by each function? or What if the error in a Result is dynamic and we don't exactly know its type? How are we to handle such scenarios? Also, there is std::error::Error which is a fundamental trait for representing error values i.e. representing any E in a Result<T, E>. We need to learn a little more about this Error trait.

Don't worry, we can always learn more. But having solid fundamentals will help in understanding more complex topics. I hope this introduction blog has helped some of you to understand errors and error handling in Rust.