In Python it doesn’t. It would be interesting to construe another language that did that, but it would be even more off topic
You are taking one specific example, whereas I am making a general point.
Exceptions are normally regarded as ‘exceptions to the normal flow of the program’. These are often errors, but are not necessarily so. You can throw an exception to indicate any kind of condition to be handled by higher level of the program Calling them errors is not acknowledging their full usage.
I don’t understand. You are saying
if (try_something()) {
do_something()
} else {
try_something_else()
}
Wow I didn’t mean to stir up a hornets nest on coding style.
There are definitely places for try/except clauses and for if/elif/else clauses. I guess to me it comes down to catching errors with the try/except clauses and controlling their impact. There are times where an error occurs and it should not be a critical error and a try/except clause allows you to recover from that situation. In those cases the try/except clauses are needed. Where I have an issue is where functions return an error as a valid response. For example lets say I have a function to get the light switch associated with someone’s room based on a dictionary that is passed in. My function returns the switch entity. If the person is not in the dictionary, I can do one of two things. I can return a key error, or None. Which is more appropriate? Both work. But “my” style would dictate that I return None so that I can easily test for it in an “if” statement.
Maybe it’s just a paradigm I need to get over. But to me errors are for catastrophic problems that we didn’t expect and really need to stop the program for.
But like I said, maybe it’s just me. Just like there is more than one way to skin a cat, there is more than one way to write a program.
Agreed they are another tool we can use. There is a time and a place for every tool in a language. I just question if we all (yes including me) get into the run of using the same tool all the time and forgetting about the others we have that might do a better job. Personally, I think raising an error to handle a known state in the code is using it where other solutions would be better. But that’s just me. Each to his own…
It may just be history and habit on my part. When I have looked it up in the past it has always been a part of error handling. It’s probably just a paradigm shift I need to go through. It’s what happens when you have been doing something for 30 years and are making a transition into yet another language. It’s more like PLSQL than “C type” languages in this case.
This is a great discussion, let me add by saying that I think you all should read this response from Raymond Hettinger on this topic. Raymond is a core developer to the language and has many, many great talks that explain some of the intricacies of the language.
it python it does if the function is constructed to do it.
yes and no.
in no languages i know there is a “if (try something)”
you dont try to compare values, you compare values.
in the line if (try_something()):
try_something() must be a fuction that returns a boolean in any case.
so yes it would be bad if you would actually try something. and no if it is a function that returns a booleabvalue, but then the name would be misleading.
@turbo explains it just like i see it. i can see the additional value from try/except, but i see it absolute as an extra tool and not as an replacing tool.
if i create a function there are two possibilities:
a) it is used to return a value and used like myvar = somecalc(), that would leave you with a filled myvar in any case
or
b) it is used to perform an action then it would be used as someaction() and would return nothing.
the b) case could be extended to returning a boolean that tells if all actions were handled without error.
i know that a lot of “old rules” are not normally used by every one anymore, and a few of them are not needed anymore in some cases and in some languages.
but that doesnt mean that those “old rules” have no value at all, in my eyes…
The problem I am trying to point out is that self.args[“overshoot”] gets referenced before the isfloat() function is called, and causes an error if it doesn’t exist.
To make the code equivalent to my try…except example here it needs to check that “overshoot” exists in args first. Something like
self.overshoot = 1.3
if "overshoot" in self.args:
if isfloat(self.args["overshoot"]):
self.overshoot = float(self.args["overshoot"])
else:
self.log("Argument overshoot must be a float. Using default 1.3",
level = "WARNING")
The link SupahNoob gave in the previous post is far more informative than anything I could say, so I will not spend any more time on the subject.
