Stream: ideas

Topic: basic-cli exitWithErr

Anton (Jun 25 2023 at 14:31):

In this basic-cli PR we replace Process.exit 1 with Task.err 1, what do you think about making this Task.exitWithErr (which calls Task.err 1)?

Anton (Jun 25 2023 at 14:31):

This prevents the use of what may appear to be a magical constant (1) to those unfamiliar with exit codes

Richard Feldman (Jun 25 2023 at 15:04):

would it always use 1?

Richard Feldman (Jun 25 2023 at 15:05):

I always struggle with figuring out which error code to pick, to be honest...I'm not sure what all the conventions out there are :sweat_smile:

Anton (Jun 25 2023 at 15:15):

2 could be used for user errors like invalid options or missing arguments but it seems like it has basically no impact if 1 was returned in case of a missing argument. I would still allow users to call Task.err myExitCode for the people that want that.

Brendan Hansknecht (Jun 25 2023 at 15:46):

I would do Task.exitWithCode <errorCode> or Task.errWithCode <errorCode> and just make it more explicit even though it just would call Task.err

Anton (Jun 25 2023 at 16:33):

Yeah, those may be best, I think they would help prevent confusion about the I32 in main's type

Richard Feldman (Jun 25 2023 at 17:50):

something to keep in mind is that in the future, Task will be a builtin module, so that would have to be moved

Richard Feldman (Jun 25 2023 at 17:52):

what about having an opaque ExitCode type, and then a helper function with the type I32 -> Task * ExitCode

Richard Feldman (Jun 25 2023 at 17:53):

so then the type of main would be main : Task {} ExitCode

Anton (Jun 25 2023 at 17:53):

I like it :)

Brendan Hansknecht (Jun 25 2023 at 18:19):

You still could do Process.exit and make it do nothing but return a Task.err? but yeah, making exit code opaque works too

Luke Boswell (Jun 25 2023 at 23:05):

It would improve error messages too I assume. When people try to return a task to main without handling the error case. Actually will this prevent just using stdout.line and mean we always need additional logic to handle erroes?

Richard Feldman (Jun 26 2023 at 01:28):

no, because Stdout.line returns Task {} *

Richard Feldman (Jun 26 2023 at 01:28):

so in the same way that it currently works with I32, it would work with an opaque type, because * unifies with anything! :smiley:

Brendan Hansknecht (Jun 26 2023 at 03:06):

That said, stdin and maybe also stdout should return errors given they have a few failure cases. Instead the app would panic in rust and crash

Brendan Hansknecht (Jun 26 2023 at 03:06):

So we would actually want it not to return *

Brendan Hansknecht (Jun 26 2023 at 03:06):

So the error would need to be handled if we ever update that

Brendan Hansknecht (Jun 26 2023 at 03:07):

For stdin it is more clear cut given you need to know when an inputted file ends. For stdout, still probably nice to know if the output pipe is closed (not exactly sure other error cases)

Anton (Jun 26 2023 at 10:22):

errWithCode : I32 -> Task * ExitCode

Can I add it like this to basic-cli/Task.roc @Richard Feldman?

Richard Feldman (Jun 26 2023 at 11:15):

I think we should figure out a different module for it to go in

Richard Feldman (Jun 26 2023 at 11:16):

because if we put it in Task now, we're just going to have to move it once Task becomes a builtin - so might as well figure out where it should go now instead :big_smile:

Anton (Jun 26 2023 at 12:33):

Process.roc is gone in the latest basic-cli but we can bring it back and put errWithCode into it.

Richard Feldman (Jun 26 2023 at 13:00):

seems reasonable! :thumbs_up:

Richard Feldman (Jun 26 2023 at 13:00):

Process.ExitCode makes sense to me too

Richard Feldman (Jun 26 2023 at 13:02):

:thinking: might someone expect a function with the name Process.errWithCode to immediately exit?

Anton (Jun 26 2023 at 13:58):

How about Process.errorExit?

Luke Boswell (Jun 26 2023 at 20:17):

Process.exitWithCode maybe?

Anton (Jun 27 2023 at 08:59):

exitWithCode does not really show that an error ocurred

Last updated: Jun 16 2026 at 16:19 UTC