-1

Sometimes I get the feeling that I'm abusing of the try/catch formula. Maybe I'm just paranoid about good coding practices, but I was wondering, would you consider a bad idea to use try catch to avoid borderline crashing situation?

Let me explain: let's say you have something that changes overtime, and you know that it could happen that it goes to a division by zero or to an array out of range exception. Quite often, it happens that the only thing that you would do in those case would simply be closing the method with a return;. This would require trying to understand in which situations the exception would occur, and then return in those cases.

In many cases this could be a painful task, and this is when I simply catch what happens and return.

        if (/* Potentially multiple peinful search for crashing points*/)
            return;

I do

        try
        {
            //I know it's going to crash here sometimes
        }
        catch { return; }

Sometimes this is very heandy, but it feels like kinda cheating. To make an example: I was just coding a thing with two TrackBars interacting with each other, and in certain circumstances if one of the two is brought to Min or Max it would create a division by zero. I am just happy with the UI staying at the very ValueChanged event before the crash, so this solution would be just fine.

What do you think about this? Is it considered some kind of horrible coding thing, or people does it?

  • 1
    "What do you think" is fishing for opinions. That's not a good way to ask questions as there are many different valid answers to such questions. Here's a similar question that has a few answers: https://stackoverflow.com/questions/3335376/why-do-good-programmers-sometimes-silently-swallow-exceptions – P.Brian.Mackey Apr 13 '18 at 18:08

3 Answers3

1

well, try/catch have the idea of try something, and catch the exception if something goes wrong. When you catch the exception, if you just hide the error, you never know what happning with your system.

For example: if you put a try/catch in a method to avoid division by zero, and you have a validation when the user put zero on the input, if someday this validation stop work, you'll never know what happned with you system. And this can cause another problem in the future, most larger, and more expensive to fix.

So, my sugest here is: you can use try/catch for alot os things to avoid ugly error on the screen, or crashs on the system, but you have to make a way to store the exception, and, if possible, warn you about it. I have the custom to manipulate the message and show for the user, something like that:

"An error ocurred on the system. Please, send a message for the support with the code error: ER23421".

And i store the exception on the log file, with the error code (that is just a index on the file, to find the log most easly).

So, you can use try/catch, but NEVER exclude the exception of the system.

0

You basically use try and catch block to provide proper handling of exceptions.

In other words, here is an example of "Proper handling of exceptions" when you catch an error:

  • Log it for future enhancement of your product,
  • You notify the user for example that an error has occurred
  • Give a meaningful message what to do for this error
  • Redirect the user to different page or UI or continue with the workflow of your program.

This is just an exception, now if you are doing try catch block to stop your program for crashing, without meaningful process of handling it, has no significance on your code and you should need to add additional process to it.

Willy David Jr
  • 8,604
  • 6
  • 46
  • 57
0
  • When you expect the exception it is misuse.
  • When you control program flow it is misuse.
  • When you don't handle the exception it is misuse.
  • When you just don't want to do proper testing it is misuse.

Here you have 3/4. Not paranoid; code smells.

TaW
  • 53,122
  • 8
  • 69
  • 111