Error processing?

Question

Programming

The function does some work and returns a result, but something can go wrong in the course of work, and the result will not be received. There are actually two questions:
1. what to return in case of an unsuccessful scenario?
2. how to report a bug?
For example, the function calculates the sum of two positive numbers, 3 and -2 were passed to the input.

Answer 1

Eksepshen throw out, of course. Let the one who called with the fig parameters figure out what to do with it.

Answer 2

Consider another example: the procedure for finding something. We seek, we seek, and we cannot find. How to report the reason for a failed search? In this situation, you can return an empty list or null.

If we did not find anything, then we simply output an empty list. And this is logical, because you were looking for something in the correct list, but did not find anything, so you returned an empty list.
If, when trying to search by data, something abnormal happened (the database fell off, the file was no longer readable, etc.), then you need to throw an exception, catch it and process it. It is also desirable for the user to show. that an error has occurred.

Answer 3

McConnell recommends (as far as I remember) - if possible, split the function into two, for example, isSearchRequestValid() and doSearch() if something went wrong in doSearch(), then this is an exception, but the user gets a "Server error" and the developer gets an alert with trace.

Answer 4

If you're writing in something like Haskell or Scala and the function is pure, you should return None on failure and Some(X) on success. That is, use the Maybe or Option type. If the function is not pure, or you are writing in the wrong language, you should throw an exception.

Answer 5

Everyone here will advise you to throw out exceptions, but this is a very holistic question. In this matter, I do not support my beloved Robert Martin, but I support Google. Actions are needed only when a disaster has occurred and if the program is not stopped, the fate of the planet will be in danger. If not the planet, then the user. In other cases, the function does not have the right to decide that the time has come to completely stop the program, which means that it is impossible to throw an “exception” without exceptions.
Specifically, in your example, I would generate a warning and return false.

Answer 6

If an error occurred (including during the search), then an exception (if any) is unconditional. Those. in the case of a search, if we cannot find it due to a database connection error or incorrect search conditions.
And if we can’t find it because there is no element and this is a normal regular situation, then use a special return value. In dynamically typed languages, this is typically None, null, or a similar type. If None can be stored in a collection and is a valid return value, then for example in python it is common to create a class named type NotFoundError and return the class type. It is guaranteed not to be a valid value.
Static-typed languages ​​use either something like boost::optional i.e. structures from a value and a flag, or return a pointer / iterator for which there is a special empty value.

Answer 7

There is no need to “force” an error where there is none. An empty result is also a result. But there are also mistakes. The best example of how and in what cases it is done "in an adult way" is ... all of a sudden ... a database server. The simplest and most understandable example of when an error occurs and when the result is empty:
If you send a correct query , for example, "SELECT * FROM table WHERE field1=100" but the table does not contain such records in which the field1=100 field, the server will correctly return an empty response to you .
However, if you send a deliberately erroneous request to the same server, like "SELECT * FROM there_is_no_such_table_WHERE and_there_is_no_field_too_to_all_buy'" the server will return an error to you . Similaran error will be returned to you if the server has a timeout, deadlock, or something similar.
Approximately, the user expects such behavior from your application. Don't put people in "cognitive dissonance", the principle of least surprise is a good principle.