Popular posts

Marco Alka

Software Engineer, Technical Consultant & Mentor

Feb 25, 2018

I think that Rust's approach is very good and superior to everything else I know. It's even something which can be implemented into other languages.

Basically, there is no throw or additional channel, which communicates errors. Instead, when something can go wrong, you simply return a Result<T, E> object, which has to be handled in order to process the result. What you can now do is either handle the error and try another call, or have the error bubble up through all function calls, until it hits an API or user-facing code, which then can automatically handle the exception, or display it. The advantage the regular function result is used to communicate the whole result of a call (not only the success one), and it enforces proper error handling without requiring developers to read the docs to find out that your function actually might throw an exception.

In Rust, there are additional libs, which add error-chaining, scoped error handling, etc. to the mix, but all that stuff build on top of the core mechanic of Results, which are used throughout the std lib :)

Another piece of the puzzle to better error management is to get rid of error whenever possible. For example by using optional values. In all cases, where there might be a value, or might not be a value, you just say, that there is an object, which stores the state of something being there or not, and if there is something, also stores the value. That way devs are forced to handle the case when there is nothing. Not doing so is more difficult than just hoping that there is no null . Again, Rust has a stdlib struct for that: Option<T> .

stuff ;)

Feb 26, 2018

Hmm thx, I will read a little more about that.

I heard that rust had such things I am in the the "we love programming languages" meetup and rust got presented 2 years ago.

Those things got mentioned there several times about taking over errors results. But till now I didn't take time to read up on the error handling model :)

I mainly focused on reading the memory handling, implementing basic functional and didn't find time to implement something on the side so far :)

j it's so simple, you will understand it immediately by just seeing an example. By the way, I linked the docs for Results and Options in my post, but the code tag removes the link style.

// The function signature communicates that an error might happen.
// Either way, the Result will have to be handled.
// The result and error are both returned as String.
fn i_might_fail() -> Result<String, String> {
  // get_rand_number() is a (undefined) function returning a random number between 0.0 and 1.0
  if get_rand_number() > .5 {
    Ok("Success")
  }
  else {
    Err("Oh no, we failed")
  }
}

fn main() {
  let result = i_might_fail();

  // Handling the error case is not enforced,
  // but the developer is always reminded to do so by the return type
  if result.is_err() {
    println!("{}", result.unwrap_err());
  }
}

Adding Option to that:

fn get_user_info() -> Result<Option<String>, String> {
  let db = connect_to_db()?; // `?` will auto-return an Err, if it is returned
  let user_row = db.read_table("user", 1);

  if user_row.is_some() {
    Ok(Some(user_row.unwrap().as_string()))
  }
  else {
    Ok(None)
  }
}

fn main() {
  let result = get_user_info();

  // Handle error
  if result.is_err() {
    println!("{}", result.unwrap_err());
    return;
  }

  // Get option from Ok-Result object
  let result = result.unwrap();

  // There might be user info, but there might also be none.
  // No one knows at compile-time, but that case has to be handled!
  if result.is_some() {
    println!("{}", result.unwrap());
  }
  else {
    println!("No user info found!");
  }
}

While there are better ways to write the above code, it serves as an example :)

Search Hashnode