Easy Day

Okay, this is a repeat, but, previously I had thought that the navy seal's motto was

"The easiest day was yesterday."

This statement implies that the training gets easier. Because, on any given day d, day d-1 was easiest. But on day (d+1) the easiest day is d. This means day d is easier than day (d-1). aha, each day gets easier.

I was properly corrected today:

"The only easy day was yesterday."


Which is definitely different.

Day d: the only easy day is (d-1)
Day d+1: the only easy day is (d)

so...... on day (d+1) day (d-1) is not easy having experienced day (d)... Hmmm, so..., seems like the same statement as above.



But still, I recall admiring the training when I heard about the navy seal as a teenager... And certainly, I didn't realize the implicit series until recently, and this realization in no way decrease my admiration for the training.


And of course, I should mention that I also realize that "getting easier" may imply a growth of the trainee, that the trainer cannot keep providing harder and harder days. Which would make sense as well.

Castle haha

Castle: "Yeah, I almost ordered a Russian bride once..."
....


"A check-mate"


hahah!!!

(as in a Czechoslovakia, nationality near Russian, companion, but also a state of game play in chess, a game popular in Russia, and probably also popular in the Czech Republic)

To err or not to err

Same old question. Should we throw exception or return error code? In a long running process, what principles should we follow in the design to handle the rare, the expected, and the unexpected?

I've been struggling with this problem for about 5 years now. (shorter than the time I've been writing code)

There are many ways to analyze this, but certainly one way is to look at our goals and costs of achieving these goals.

Okay, so let's drop the act and face the facts: There will be errors and there will be cases that you haven't thought of and murphy's laws are enforced in most industry settings.


The goal is very very important. The goal here is to:

1.) run to achieve the goal of the software
2.) communicate from one piece of code to another piece of code an expected error. (program continues correctly)
3.) communicate from one piece of code to another piece of code an unexpected error. (fail, or continue gracefully)
4.) communicate to operator of program that the program is in need of immediate attention.
5.) communicate to operator of program the total amount of problem (fatal or not) the program encountered in it's entire lifetime.



The cost of these error handling modes are consumed are:
1.) immediate cycles in cpu to generate error message, log to disk, etc.
2.) network/storage costs to store this error.
3.) human attention: oncall receives a message marked "PRODUCTION ERROR!"
4.) machine/human resources required to analyze the log of error and notable conditions.


Considering these aspects may help me to design the error handling system.