Return `Result` from `main`

[Ericson2314]

Rust's current error handling story is quite good for programming in the large. But for small programs, the overhead of matching the outermost Result, printing the error, and returning the proper error code is quite tedious in comparison to temptation of just panicking.

Furthermore, interactive tools shouldn't print a message implying the program is broken on bad manual input, yet such an "internal error" is exactly what the panic message applies. So there is no nice, succinct way to handle input errors with bubbling results or panics.

Allowing main to return a result would make our error handling story both compositional and succinct on programs on all sizes. Furthermore, should there be any platform-specific requirements/idioms for error-codes, etc, we can handle them transparently. While this does make main a bit more complex, there is already a shim between start and main with both C and Rust, so we're already down that rabbit hole.

I was told by @eddyb this was already a wanted feature, but @steveklabnik didn't see an open issue so I made this.

[steveklabnik]

I know @chris-morgan has thought about this a bunch and has some concerns

[nagisa]

I really remember a lot of discussion about this happening, but can’t find anything either, sadly.

Off the top of my head some points raised during these discussions:

• Unclear what to do with Ok value, unclear what to do with Err value. What both of these variants may contain?
• Return an exit code instead;
• Return Option instead, if None, exit successfully. A bit counter-intuitive that None is a success and Some is a failure.
• Should main become somewhat special and the only overloadable function in rust? What about people who simply don’t care?

[Ericson2314]

1. Restrict to Result<(), SOMETHING>
2. Should return appropriate exit code, and no panic-like extra text because IMO if the error can be propagated to the top it is not an internal error.
3. Weird, and doesn't help promote idioms
4. I've long argued we need parametrized crates like ML functors. Then any crate can call a not-yet defined function. Then any library can define std::start and export it's own hook (like SDL in C). Indeed std can use this to define start and call main. [As an side bonus, this would also allow log avoid using allocation and dynamic dispatch.] This is better than some main-specific hack, but IIRC this route has been resisted before.

[eddyb]

@nagisa Rust has overloading via traits, so this could work:

trait MainReturn {
    fn into_error_code(self) -> i32;
}
impl MainReturn for () {
    fn into_error_code(self) -> i32 { 0 }
}
impl<E: Error> MainReturn for Result<(), E> {
    fn into_error_code(self) -> i32 {
        if let Err(e) = self {
            write!(stderr(), "{}", e).unwrap();
            1
        } else { 0 }
    }
}
#[lang="start"]
fn start<R, F>(argv: *const *const c_char, argc: u32, main: F) -> i32
   where R: MainReturn, F: FnOnce() -> R
{
    with_runtime(argv, argc, || {
        main().into_error_code()
    })
}

[daboross]

I'd argue that it is very easy and simple to just .unwrap() a Result returned from a try_main() function.

fn main() {
    try_main().unwrap();
}

fn try_main() -> Result<(), Box<Error> {
   // ...
}

To explicitly do this is just 4 extra lines of code - I would argue that adding this implicitly is just not worth it.

[Ericson2314]

@daboross Sorry, but did you read my second paragraph? That will print clutter the actual error with all the "thread main panicking at" business which is inappropriate for handling bad user input. It also sticks you with a single error code.

[daboross]

@Ericson2314 I guess it isn't entirely the best for some cases like bad user input - but I think it's totally appropriate for other errors which really are internal errors. One problem with having main() implicitly handle these errors is that it would be unclear what, if any, text would be included before/after the error.

With error codes, it can really be very simply solved by a single match or if let statement and then a call to exit() manually.

It may turn out to be good to implement this, or not, I'm just here stating my opinion from my experience working with creating programs in rust.

[Ericson2314]

By returning a Result, a function is "kicking the can", effectively saying that the error is not it's fault. It follows then that any error error returned by main is the fault of whoever spawned the program and not the program itself. Sometimes internal errors get bubbled up a bit, but those should all be unwrapped at some point.

I totally agree that trying that it is not obviously clear how the error in a result should be printed, but since this is for programming in the small, and since one can handle it themselves, I find it more tolerable than I would otherwise if libstd just picks something.

[yberreby]

👎
A wrapper function can do the job very well, and this ties main() to Result: what if we want to use another type? More special cases?

I'd argue that adding 'convenient' special cases is not a very good idea in the long run; it increases complexity and coupling between std and the language. Binary crates should choose their own error handling strategy, be it by writing it themselves or using one from crates.io.

Rust is not a scripting language. I think we should strive to avoid too much features designed for narrow use-cases bolted on it. Weren't ~ and @ removed because they could be implemented in libraries?

[ArtemGr]

When a function returns an error it thus handles the responsibility of doing something about the error to it's caller.

For example, when a function that reads a file returns an error, the caller decides what to do about it, to print an error or to ask the user for another file name or to skip to the next file or to panic, etc.

This chain of responsibility usually ends at main. While other functions can delegate the responsibility of handling an error to the calle, the main can't, cause nobody else has any idea of what to do about the error.

Should we print a message or simply return a -1 error code to the OS? What about a GUI program, should it display a error message "dialogue"? Only the main knows this.

[eddyb]

@filsmick There is already coupling between std and the language - check out std::rt::lang_start.
It's also quite fragile and prone to race conditions due to the use of a global "exit status".

If the trait bounding the return type of main is exposed from libstd then any crate can write a novel implementation for a type of its own.

[BlacklightShining]

I agree with @ArtemGr. main() should be the top of the chain for bubbling Results. I do think, however, that it should return an i32 (or a u8, maybe, given that exit statuses are effectively u8s on *nix). Currently, we're advising people to do silly things like fn main() { std::process::exit(main2()); } fn main2() -> i32 { /* useful stuff goes here */ }—I hope that's not seen as a permanent solution.

At the very least, there should be some platform-agnostic mechanism to cause the program to exit gracefully (unwinding stacks, dropping structs, etc) that could be used as a drop-in replacement for returning from main().

[eddyb]

@BlacklightShining That could be achieved with a type wrapping the exit code and implementing MainReturn - std could provide that type with platform agnostic helpers.

[droundy]

This sounds to me like a problem that is nicely handled by a utility function in the standard library, which could be named something like exit_on_error, and would accept a FnOnce as its sole argument. This could actually be useful either as main or as a convenience function for cases where you simply want to exit on errors, and don't want to bother propagating then up the stack.

[ticki]

I'm not sure what's the pros over the current way

@Ericson2314

1. Restrict to Result<(), SOMETHING>

That pattern is redundant and can be reduced to Option<SOMETHING>.