[][src]Constant blogs::_2018_::july::_26_

pub const _26_: ()

Errors in Rust


Before Rust, I've coded Java and Ruby. Both languages allow developers to throw exceptions at will. I would prefer the word "encourage" over "allow", just to emphasize the use of throwing exceptions.

That would become a problem. Big and tough.

You can get exceptions thrown at, while using official API libraries provided by "enterprises". All the time. I mean the "enterprises" can throw official exceptions at you, all the time. The official documentation often is a joke. When that happens, you know you're officially dead. Ha-ha.

Here comes my rant to those enterprise developers, encoded via sha1sum: d71a0df4e85066445a0ed0f4fe9b5b06dd681a20. I'm sorry to readers, if you're not one of those "enterprise developers", please ignore my rant.


Now in Rust, developers can call panic!(), or ::unwrap(). But that is considered bad practice. Even if developers like to call those functions, at least, Rust does limit the numbers of "exceptions" to a very small set. It's much more easier to audit the source code.

Rust encourages developers to use Result<T, E> instead. In my experiences, this helps me write better code.

One thing that's different: stack-trace.

While handling exceptions in Java, I can print the stack-trace to stderr. It's useful. But in Rust, as far as I know, there's no way to obtain a similar "stack-trace", unless you crash your handling code yourself. So I reverted to using the error messages. I put the path to the messages like this:

This example is not tested
match this_function() {
    Ok(_) => (),
    Err(err) => eprintln!("this::module::at::this_function() -> {}", &err),

Tiny text, but turned out it helped a lot.

Final words, I sincerely hope Rust developers come to prefer Result<T, E> over panic!() or ::unwrap(). I go first, in case you use one of my crates: it's a guarantee that there are no panics. In return, it would be great if you do the same :-)