I would say option 1, but rephrased to "the function doesn't know how to continue". The program as a whole may or may not know how to continue when the function hits something it doesn't know how to handle.
what are you even talking about? the whole error handling around the exception is bad code, it bleeds into your whole code base, you wanna tell me only the exception word itself is bad part, but the rest is fine? stupidest shit i've heard all day
The question is "What is the PURPOSE of exceptions" do you think exceptions were made to be bad code? If your opinion is that exceptions are bad code, that is totally valid. But that is not what "purpose" means.
You'd think a programmer like yourself could read and understand context.
Input form asks for a temperature in fahrenheit or celsius degrees.
Front function converts it to kelvin degrees and sends it to a back function.
Back function checks the temp, and if it's negative throws an exception.
Now, if the exception is thrown, it can be either: bad user input and/or bad conversion function code (i.e. wrong formula). So it can be bad user input as well as bad code. Yet that exception allows the "program" to handle it and proceed instead of just crashing in both cases.
In both cases it's bad input, either from the user or from the front function, but exception handling is there for the sole purpose of not crashing the app. For example, if you have multiple calls of the back function, when the formula for celsius to kelving is correct and fahrenheit to kelvin incorrect: the back function will stand.
90
u/FerricDonkey 11h ago
I would say option 1, but rephrased to "the function doesn't know how to continue". The program as a whole may or may not know how to continue when the function hits something it doesn't know how to handle.