Over the top Error handling?

Newbie & Debugging Questions
#1

I am in the process of fool proofing 2 time based classes I have created.

Currently any error made by the user causes a run time exception with a given detail, but how far is too far? Should I be using normal exceptions and letting the user catch the error? The things that will cause the error are common sense, should not really occur.

For example.

A user creates a new clock, they set it as a 12 hour clock. They then try to set the time to 17:00:00 (HH:MM:SS), this throws a run time exception telling them that value is out of scope for a 12 hour clock.

This seems like a valid reason for throwing such an error, but in what cases should I be letting the user catch it?

I was thinking in a situation like so:

User creates a Stopwatch, sets the time to 5 seconds and then tries to reset it without stopping it, this causes weird behaviour (it resets the countdown time, the last update time and the current total time in milliseconds, resetting while running could cause the clock to run forever if the user coded it wrong). Should I let them catch this error and stop it in the catch block?

Or simply do nothing? It is clear they want to reset it but maybe they forgot to reset it.

When should I use each? I understand that a run time exception should be thrown if the program simply can’t do without the attempted code execution, and normal exceptions are for non dependent code/user input errors.

What are the exceptions (no pun intended) when deciding which to use?

#2

evertime someone (a developer) is using your lib in a wrong way it is an programming error and you should throw an unchecked exception which hopefully terminates the app as quick as possible. Checked Exception should only be used for real “exceptions” something which is not a programming error (e.g. “a file doesn’t exist”).

ps: you should never use exceptions for logic

#3

Sorry for not answering the question…but why wouldn’t I be able to set the hour of a 12 hour clock to 17:00:00 and have your program parse it accordingly? That seems like a big restriction for little to no benefit.

#4

Actually I was considering doing this.

Why would you create a clock with the constructor:

public Clock(double timeFactor, ClockFormat format)

Clock clock = new Clock(1, ClockFormat.HOUR_12);

Then decide to change it later? Actually you can change it at any time by simply changing the clock format. Fair enough you never seen this constructor until now but still…

But in what situation would you want to parse one format to another? Serious question because I cant think of one lol

#5

Perhaps another person is working on the same code base and prefers 24hr time? Not sure! Just seems like an unnecessary step. The less ways a user can mess it up, the better

#6

Each class should support the least amount of functionality possible (don’t allow changing the Clock format, unless you see a use case). Any time something fishy is going on (stopping while not running, starting while running, etc, etc) immediately fail with an unchecked exception: never allow your objects to reach an undesired/undefined state (running with a timeFactor <= 0.0 or NaN). Sometimes parameter validation results in code duplication, for example if multiple field values implicitly define a single ‘state’: in such cases you can move the parameter/field validation into it’s own method, allowing you to check whether the entire object is in a valid state.

TL;DR:

  • it’s the API’s role to be strict
  • it’s the callsite’s role to be lenient