How to avoid premature optimization? Or how, not knowing what will happen later in the project, handle exceptions?

Question

WPF

void fun()
        {
            int a = div(4,6); // внешний код, не будет знать как-там что проиошло, но может когда-то знахочет знать
        }
        int div(int x,int y)
        {
            try
            {
                return x / y;
            }catch(Exception ex)
            {
                return 0; // вот тут потеря информации. К примеру сейчас мне всю-равно.
                //А вдруг потом при обновлении, мне понадобится
                // извлечь  сообщение, и сохранить значения Х,У допустим.
            
        }

I've run into this problem many times (to put it mildly). It's not described anywhere.
Let's say you are making an application at the development stage, it may turn out to be such a situation that premature optimization will begin, or how to say, you will start wasting time on trifles.
For example, suppose this simple example, there is a Dataset, with a Path and Time awarded to N people. Let's say we need to find the speeds of all. Then choose the fastest.
Now. Such a situation, the DataSet may not be accurate, and somewhere the time will be 0. Okay Let's handle the exception and just skip them and forget !
And here is the most interesting, What if in the future I need to print the number of people in this array with time 0. Let's say, for example, make a button, show the number of athletes with 0-time. What should I do to change the code, and what if this code is in another dll, should I change it?
If I start immediately processing and finding all such situations, then I can get away from the main task (wasting time).
The example is the simplest, but sometimes it can be more complicated. and not clearer, especially when increasing the tasks for the finished project.
Are there any tips, Balance and optimality.

Answer 1

If you can’t change the code later, well, I don’t know, you cast it in stone and launched it to the moon and you don’t want to be embarrassed in front of your grandchildren, then do everything at once and for centuries. The rest of the people have no problem releasing version 1.1

Answer 2

Interfaces were invented for your situation .
Look, there is an output logic (Kotlin, I hope it is clear what this code does):

interface Report {
  fun getAverageTime(): BigDecimal
}

fun printReport(report: Report) {
  println("Average time: ${report.getAverageTime()}") 
}

We get data from a report. And at this point, we don’t care much about exactly how this data is calculated and how 0 is processed. This is the logic of the report. Moreover, we can have several different implementations of the Report interface, each of which handles this case in its own way, up to throwing an exception and, as a result, an error occurs (handling such an exception is beyond the scope of this example).
Now we need to add one more parameter to the report:

interface Report {
  fun getAverageTime(): BigDecimal
  fun getCountWithZeroTime(): Int
}

fun printReport(report: Report) {
  println("Average time: ${report.getAverageTime()}") 
  println("Participants have zero-time: ${report.getCountWithZeroTime()}")
}

And no premature optimization, just structured code.

Answer 3

if it seems to me that the information about ignoring is useful when debugging,
I write the output to the debug console in the ketch.
If you are 100 percent sure that it will not help later in the analysis, then
try{
// actions
return an honest result
}catch(Exception ignored){}
return the default value