Q In a console application the normal behaviour for a usage error is to report it and exit.

What is the 'correct' behaviour for a GUI application?

  • should it exit or continue running?
  • should it write to stderr or open a message box
  • should it write to the application log file if there is one?


I looked at some existing GUI applications for inspiration:

  • word - accepts positional command line arguments which it treats as names of files to open. Unknown options are ignored.

  • chrome - accepts positional command line arguments which it treats as URLs to open. Unknown options are ignored.

  • devenv (visual studio)

    • reports command line errors to the terminal if launched from the terminal.
    • reports command line errors as a messagebox if launched from a shortcut
    • exits either way
  • emacs - accepts positional command line arguments which it treats as names of files to open. Unknown options are ignored.


I was slightly nonplused by an argument from colleagues that the right thing to do is just to open the application anyway and ignore the errors (I'm firmly in the "silently ignoring errors is bad" camp).

My feeling is that the 'right' thing to do is as the visual studio example above. Report an error and exit. Using a messagebox if there is no stderr channel.

What reason could there be to ignore usage errors?

Some possible arguments:

  • The command line is for expert users and failure to open the application would confuse them.
    This is possibly condenscending. It also doesn't explain emacs which is firmly in the Posix camp where doing command lines right is more important.

  • I think the main one is that in general "Errors do not stop a GUI application" is drummed in the GUI Ux mindset. In the case of command line processing the application hasn't really started yet so you could argue it shouldn't apply.

I looked around for GUI design guidelines that might cover this but I have not found any so far. The two below are interesting for context as they discuss error handling though not specifically the command line.

https://www.sapien.com/blog/2015/01/15/manage-errors-in-a-gui-application/ https://www.userjourneys.com/blog/ux-guidelines-for-error-handling/


1 Answer 1


I agree with your uneasiness of ignoring erroneous commands/parameters. Whether it is a typo, or a misunderstanding of the manual (hey, did you read it?) - the user should be alerted to the fact that the program works differently (because the argument cannot be recognized) than the user expected (I assume nobody types in something doodly only for it to be ignored).

Whether that is a

  • an error message on standard output (or wherever the command was typed)
  • a message box to be confirmed, and the program terminating
  • or the program starting up the GUI and displaying a message box in addition

is up to the situation, I think: Are there options which cannot be "repaired" on the GUI? When is the error detected and how costly is it to start up the GUI framework? etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.