Open marty-sullivan opened 4 years ago
I would say, this depends on whether you consider such errors to be bugs in the caller’s code or not. If they are legitimate conditions that could arise in the normal use of the module, then yes, having distinctive exceptions that can be caught is useful. Otherwise, no.
Consider a script that looks at the same location every day and some days per year this error is thrown because in that location "Sun is always above/below the horizon at this location on this day". Therefore, this is not an error in the caller's code and having a distinctive exception would be useful.
I agree that better error handling would be useful, although I suppose one could isolate these errors without needing to parse the error message by calling calling Daylight() and seeing if its value is greater than zero. (Note that I haven't tried this yet - I just downloaded the module. Hopefully it does not throw an error when the sun doesn't rise on some days at a given time and location. That too could be handled, but it would make more sense for the function to just return zero.)
Hello,
Thanks for this great module!
I would like to request better error handling for this project. As it stands, whenever anything goes wrong in the module only a ValueError is thrown (e.g. 'Sun is always above/below the horizon at this location on this day')
I'd like to request that custom Exceptions be raised for these various events (e.g. SunAlwaysAboveHorizonException or similar). This will allow for much more robust and consistent error handling. Right now, the only thing I can do is parse the error message and that is very dirty and prone to problems as you update the module.
Alternatively, logging a warning plus creative use of datetime.min and datetime.max could potentially be used to not raise an exception at all but still return a usable date range for comparisons.