RFC: behavior on errors

This is specifically about RetroForth/nga.

In the #retro irc channel, ae_chep said:

I was imagining a forth development experience to be like a conversation had with the interpreter. In which case to be hung up on is rather unpleasant

This is a quite reasonable way to view the expected experience. In the current system, I just report errors and exit, but that's not necessarily the best option in all cases.

Rick suggested adding hook-able words for logging/instrumentation/alerting. This seems like something that would be worth adding.

I think we should look at adding words for this, probably under the err: namespace. It might be worth having two paths. In the case of running a program directly, have these default to reporting error and exit. But in the case of an interactive session, it might be better to offer a way to try resetting the system state to something sane and allowing execution to continue.

Thoughts on this?

Assigned to
1 year, 1 month ago
1 year, 1 month ago

~rickcarlino 1 year, 1 month ago

Hey everyone,

I wanted to jump back into the discussion we had on Patreon.

With regards to the new comment:

Being hung up on is rather unpleasant.

I totally agree with this sentiment. I've personally experienced this issue, and it's not fun. After hearing more about the context of the situation, I think it would be helpful to determine at runtime whether the -i (interactive) flag has been passed or not.

For example, if I'm using Retro to serve requests to TCP sockets in a production environment, I definitely wouldn't want it to swallow errors when it runs into an error. But if I'm working in interactive mode (trying things out / doing dev work) it would be great not to have to restart my environment every time I make a mistake.

So yeah, I hope that clears things up a bit! Thanks for adding more context to the conversation.


Register here or Log in to comment, or comment via email.