re: Identifying the dirt in our code - names, functions, and comments VIEW POST


Thanks for the article!

Could you clarify about the section "Avoid returning an error code"? Instead of returning an error code, how should I then structure my code?

I usually raise an exception if an error occurs and do a try/catch from the calling function.


You could return a message and not an error code. Another option is (in some cases) to change the user flow, redirecting the user to another page, and another option is to just log the error instead show to the user.

The problem with returning an error code is that the user won't know what the error means.
And raising an exception you'll break the application leaving the user frustrated.



I misunderstood your original article and thought you meant that we should not be returning error codes in our functions. I think it's ok to return error codes/throw exceptions in our functions but it should be caught (or we should detect the error code before it reaches the user) and display a friendly error message to the user.

code of conduct - report abuse