Which is a better approach?Preventing an exception or Handling it

Question

I want to block the user from running an exe file by double clicking it.The exe file only executes with the help of the command prompt.When the user double clicks the exe the args value will be null.

    static void Main(string[] args)
    {
        //Preventing the Exception

        if (args.Length > 0)
            Application.Run(new Form1(args[0]));
        else
            MessageBox.Show("This File Can Only Run In CMD");
        //Apporach2 Handelling the Exception
        try
        {
            Application.Run(new RecycleBinCleaner(args[0]));
        }
        catch (Exception e)
        {
            MessageBox.Show("This File Can Only Run In CMD");
        }
    }

[Related](https://stackoverflow.com/questions/27022501/determine-whether-console-application-is-run-from-command-line-or-powershell) — ProgrammingLlama, Jan 30 '20 at 07:43
You should not use exceptions for flow control. Use the if statement approach. — Sweeper, Jan 30 '20 at 07:44
[Best Practices for exceptions](https://learn.microsoft.com/en-us/dotnet/standard/exceptions/best-practices-for-exceptions) — John Wu, Jan 30 '20 at 07:53
1) Exception handling is slow. 2) if you do `catch (Exception e)` you catch **all** exceptions, what makes you sure that the exception you just caugh has the reason: `This "File Can Only Run In CMD"` ? — Mong Zhu, Jan 30 '20 at 07:54
This error message is misleading. Command-line arguments can be provided by any `CreateProcessW` call -- whether from the Win+R menu, a shell shortcut (.lnk file), a scheduled task, or a console-based shell such as CMD, PowerShell, or bash. Also, the only thing that runs "in" CMD is a batch script. External programs are run "from" or "by" CMD. They may inherit and attach to the same console as CMD for their standard I/O, but they aren't "in" the console either, and CMD's only thread is blocked in a wait. A console is just an I/O resource -- same as a file, pipe, or socket. — Eryk Sun, Jan 30 '20 at 08:21
Have you looked at the STUB file options? In the olden days of Windows programming, if you ran a program in DOS it would throw the error that it was to be run under windows only. That error message was generated by including WINSTUB.EXE. You could put a custom stub file in to do anything you wanted. What you could do is create a simple windows program that pops up a warning dialog box and write your program under another project to create a custom stub file. Compile the two together and your program (as the stub) will only work at the command prompt. — Buzby, Jan 30 '20 at 11:02

score 1 · Accepted Answer · answered Jan 30 '20 at 07:55

1

I think your approach 1 will be better since your code doesn’t need to invoke the method Application.Run or construct a new object in this case but only need to do a check for condition and throw the message back to user.

answered Jan 30 '20 at 07:55

Nguyen Pham

444
1
4
14

Ritesh Kulkarni · Answer 2 · 2020-01-30T07:52:50.450

0

Approach 1 seems to be better one. It's better to perform checks in the code rather letting it handle the exception way. Exceptions are meant to be thrown when you can't predict the occurrence of an error OR can't do anything from an error to occur. Exceptions always alter the execution of program.

edited Jan 30 '20 at 07:52

answered Jan 30 '20 at 07:46

Ritesh Kulkarni

119
7

Which is a better approach?Preventing an exception or Handling it

2 Answers2