How to handle different type of error in one function

Question

Context

I'm working on refactoring a program that saves data in a DB. This program has a Graphic Interface.
The programmer who did this program ( the one i'm working for) would like me to make this project consistent with MVP.
One of the constraints of my job is to try not change the original business code so even if the code is "MVPized" it will be easy understandable.

---

About the Code

We have a function that saves an object in the DB written in the View. Hence, instead of returning errors, it directly show error message.
Those Message sometimes are complete sentences, sometimes they are error codes.

I have ~10 possible different errors in the function : Checking if every field are not empty , with one message for each field, Checking if the values are not already used, Checking if the saving in the database as gone right, checking if an external applciation as gone right with native function to give an error message (different from checking the field for example). Every checking as its own error message with sometime a special native function called to give the error message ..

So, I moved this function into the Model and made this function return Error codes using an enumeration type ( or tried at least) but the consequence is that now I have a lot of different error codes.
Now I almost finished refactoring this function but I don't feel I did the right thing by doing this.
So my question is : Is making a lot of different error codes a good idea ? Or more precisely, is it a good idea to have a lot of different error codes in only one function ?

Answer 1

If the many error codes should be generated in a single function can be a question of how far to take the Single Responsibility Principle. MVP tells you to divide out the error detection from the reaction to, or presentation of the errors. The reasons include testability, alternate interfaces or model reusability, and they are the key to making your decision. Testability has been an easier line for me to see. Other reasons are more about your particular situation. Speculating what you might do in the future is another way to find them, but it can lead to unnecessary complication. It can be a worthy thought experiment though. What other realistic uses of the functionality would be made easier or harder by dividing or combining functions?

So are the individual error tests single things? Possibly. The error codes make sense from an MVP point of view where you separate the error from its presentation. The decision whether to divide out the logic of detecting each error into a separate function becomes art. If they are relatively simple you might see them all detected in the same function. If they are complex, testing might be easier or make more sense in separate functions where you can set up separately. Some tests might make sense to go together, for example if it's really about two values.

In summary, it depends and the surrounding code should help you decide. Consider each idea and judge them based on clutter vs restriction. Too many little parts that are really part of the same thing, or big blob that ties to many different things together.

Answer 2

Yes, having error codes is always a good idea because it easy to maintain and change those error messages when in need but the main point is to have all those error codes in one place or make it global

1. Try using exceptions in models

2. Handle separate classes to handle system error,browser error,UI error etc - if possible define the error code like if the error had already had the code such as http error codes then dont change them eg

   if (this->error->getCode() == '404') 
   {
     header("HTTP/1.0 404 Not Found");
    } 
   Errorclass::raiseNotice( 100, 'Notice' );
   Errorclass::raiseWarning( 100, 'Warning' );
   

3. Create helper classes or configuration files to handle error and error codes