Suppose our task is to implement a class A solving a certain task. And this class should not throw exceptions simply because such is the nature of the problem it is solving.

But class A uses an auxiliary class B, to which you can submit incorrect parameters. On the one hand, it would be good in this case to throw an exception, making it easier to follow debugging, but on the other hand, no one except us will use this class and waste machine time on unnecessary checks.

To be such an exception or not to be?

The question concerns only languages ​​that do not support debug / release code selection (ifdef in C ++).

An exaggerated example : a console program in which we enter a square of a square and get the length of its side. Moreover, the input area is filtered so that the user can not enter an incorrect value. Is it necessary in the sqrt function, which for some reason we have written ourselves, to make a check for the negativeness of the argument and throw an exception in this case?

If you write this check, it will be easier to catch the internal errors of the programmer, but in the release version the check will be superfluous.

  • 3
    What kind of languages ​​are we talking about? - Ilya Pirogov
  • @Ilya Pirogov, thanks. The answer to the question really comes down to a more careful search for analogues of ifdef. And in almost all languages ​​they, although not explicitly, are present. Convert a comment in response. - Jofsey
  • And I would be interested to know what ifdef analogues are, for example, in Java? - skegg

3 answers 3

The exception should be thrown in any case. This will tell you that class B has problems, and in class A you need to try to solve it or just swallow it and ignore it.

  • And how are you going to handle the problem of passing incorrect parameters? And ignoring is no different from the option "without exception", except for the cost of extra processor time. - Jofsey
  • If there is a risk of receiving incorrect data, the exception handling should be mandatory, otherwise your software product will not even be able to dream of a release-branch. IMHO naturally. - Shamanis
  • @Shamanis, as already mentioned, class A is isolated, which excludes incorrect data. But incorrect data may occur inside the program due to a programmer's error. - Jofsey
  • Disagree with @ AO)): IMHO: While I tend to two versions of the class: B and safeB ... A uses B ... - timka_s

I think some test should be done, at least during the development and testing.

  • Now imagine that you have megabytes of code in your project, and it's time to release a release version. Will you write a parser and enter special debag tags in the code? - Jofsey

It is not entirely clear from your question, answers and your comments to them, are you afraid of the errors in the release version that were not detected when debugging?

Those. in the "combat" mode, incorrect parameters are excluded, and the code left over from debugging is wasting resources.

Please clarify your question without regard to exceptions. Sometimes it’s more convenient to catch input errors by catching exceptions.

  • Added an example. Hope this clarifies the issue. - Jofsey
  • Absolutely clarified. That's a pity, \ #ifdef does not suit you. Something needs to be thought about the structure of the code, so that the release version of the debug version would get along easily. Yes, 2 versions (all the same, in life, for a megabyte project of these versions will be born ...). - avp