0

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 ?

  • How many error codes are we talking about here? – Andy Jul 25 '17 at 9:19
  • I find this question hard to answer because of how many errors and how detailed the application should be, is something we can not answer for you. What are the requirements regarding the message errors? – Laiv Jul 25 '17 at 9:20
  • Edited my question for more details – Freddykong Jul 25 '17 at 10:13
  • Is still hard to answer. For example, a single error per empty field can be summarised to Some required fields are missing. (alongside with these field highlighted and bolded in red). How fine grained should be your errors (and hence the codes) depends pretty much on your requirements. For instance, the project I'm working on right now has 250 different error messages (not codes). Are they too much? Is that good or bad? could I cut them down? (Probably) – Laiv Jul 25 '17 at 12:27
  • I don't know. I am actually in an Internship so sometimes I am asking questions like this one because in that kind of situation, I feel that maybe my lack of experience prevent me to see a better solution that maybe somebody more experienced could have tell me. – Freddykong Jul 25 '17 at 12:31
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.

0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.