What if the worst happens?

I see a lot of companies rush, rush, rush and push, push, push to get things in fast. They want to deliver new features every second if they could. However this has big risk and future problems they keep coming. I always say Prepare for the Worst and Hope for the Best!

This I find is the best saying to use, whenever you think ‘should I just do this little thing or not’. If you ever look at a problem and think something could go wrong here then put in a worst case solver.

Some of the trip ups I have see have been to do with logging, which can either be to little or even to much. You can always do with logging to save you in the live environment. When issues start happening you need to diagnose what the issue is straight away, but you can’t get the details without some logging as to what is going on.

However you should only log the things that could fail, but of course shouldn’t be. An example is, I have created a method that actions dynamic changes on multiple elements, but if one element is removed I don’t need to know about it. I just need the method to continue running, so I could put a try catch round it and then let it go with no logging. This prepares for the worst and then lets the best happen. However If I have built a method that the application needs all elements to be present, then I want to log the error for reporting so it can be fixed as soon as it is seen.

There has been sometimes that someone has added masses of logging at every section, then the server starts throwing warnings up or just falls over. So your best is that the program works as you need, but your worst preparation is you have logging to review any errors. You then also have the best prepared with as much useful logging for review as you need and also the worst is you don’t put in unnecessary logging. There is always a balance between too much and too little that needs to be looked at.

Something logging and other attributes can do is take up memory. This can then build up and take down servers, as I have recently also found. I deployed a nice new OSB service and added one new log that would be fired each time someone submitted the form. This to me didn’t seem much as it was a small file, but then once it was live there was a report about the logging from the support team. Although it was a lot of logging that could build up over time, it was also not helped that the server was full 95%. This means it could fill up at any point.

If you are going to have a well organised and dynamic server, then there should be scripts run daily or monthly that clear up the files. This could either delete the logs older than X number of days or even just package them and send to another locations. It is super risky to be running a server at 95% full and expect nothing to tip it over the edge. Regular maintenance and checks should be carried out so that this is caught at the first site.

One that all developers should be using is a good old Try Catch. If you are not sure what one is, without being too patronizing, it looks like this in JavaScript for example:

try {
//Code attempted
//Exception caught

You should use these anywhere there could a potential break even if you want something to react to it or not. For example you would put one round a submission from a form. This would then catch if it failed and for what reason, then from this you could display a notice informing the user what to do next. You could also do it for example if you are dynamically loading content in a loop, you could put one round the code within the loop. If one of the calls to get content fails it could trip over the Try Catch, but then continue getting the rest of the content. The user then need not know that something went wrong and then you can either send an error message to support or just let it continue.

These can be really helpful to stop your application from breaking in unwanted ways like with server errors, but again you don’t want to over use them and you want to be sure they errors are being picked up.

Another method to get around the errors cropping up is putting default values. I stepped into this one when someone create a switch statement, but with no default case (C#) and the variable that was being set inside was set to null at the beginning. This was working fine for some time as the cases that were there met the demand, but further down the line the content editable variable that was being checked in the switch had changed. This meant that the variable being returned was null and breaking the application.

To get around this you should first try to make the check dynamic or dynamically changeable, so when a new value is added then the new result can also be generated. The other thing that should always be done with Switch statements or any other kind of statement that provides the option, is put a Default. Example:

Switch (Number){
Case 1:
//Do thing
Case 2:
//Do this
//Or else do this then

It just means that there is a result from the statement no matter what. At best, unlike this scenario, if you are setting a variable in the statement you should always return a valid result and then handle the result. For this instance an empty string could have been returned and all would have worked fine.

These are some of the ways developers can prepare for the worst and stop stupid mistakes. If you have seen any silly things happen that could be avoided then comment below with what, why and most importantly how to fix it.


Published by Chris Pateman - PR Coder

A Digital Technical Lead, constantly learning and sharing the knowledge journey.

Leave a message please

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: