Isn't this counter to the idea in original post of putting the whole view inside a try/except? I agree. I do put try/excepts in property changes when appropriate. I always put as low level as makes sense. This just seems counter to what you were trying to do in your original post unless I misinterpreted it?
I was no way implying I wanted to use “pass” to swallow exptions.
I just wrote that as an example, I did say or log the error immediately afterwards. My major point was that recovering from errors, if you only had one try except on the entire view that caught everything, would be a major headache - not worth the effort.
Oooohh, oooh … I think you just committed a [straw man fallacy]
I am just giving you a real example of a headache you could easily run into with this method. Look here
This is the sort of error you would get. Now you have to know in your code what keys belong to what dictionary in order to do any sort of error recovery. I was just giving a single instance of how a specific error thrown that in a singular context (like on button press or property change) inside a try/except that would be easy to handle there (because you would know exactly what caused it - would become much harder to recover from because all you know is that it's from somewhere on your view.
I am not saying that there should be explicit wrapping of every function, just that having hooks that have the potential to catch exceptions at a higher level would be beneficial rather than having them go straight to the wrapper log.
I think under the hood this would just be wrapping of some sort fwiw.
I still think it makes more sense to catch uncaught exceptions on the level they are on because you may also want to handle them differently in different scenarios. Surely you do want to log them all, but in certain scenarios an uncaught exception might want you to also abort the current process you are in the middle of for instance.
I think you should write for expected and unexpected errors in the same code block, not just code for the expected type and then have the unexpected bubble up to the thing you are suggesting caught all unexpected errors.
The way I tend to code my business logic is like
# I throw this from validation functions when examining if a data is ok
class FormError(Exception)
pass
unexpectedError=False
expectedErrror=False
try:
createRecord(data)
except FormError, e:
# show user nicely what they did wrong
expectedErrror=True
except java.lang.Exception, e:
if "Duplicate record" in str(e.cause):
# Tell user unique key violated
expectedErrror=True
elif 'cannot be null' in str(e.cause):
# tell user column cannot be blank
expectedErrror=True
else:
# Unexpected db error - log and set to True
unexpectedError = True
except Exception, e:
# Unexpected python error, log and set to True
unexpectedError= True
finally:
if unexpectedError:
# Might need to short circuit or reset something etc.
elif expectedError:
# All went well or was recoverable, do something here if needed
else
# Everything went ok without expected or unexpected errors - success
So to me then it seems like you just want
except Exception, e:
# Unexpected python error
logger.info()
This part as a catch all to happen on any part of your view.
I think part of the issue with this too can be observed from my java.lang.Exception part - there are java.lang.Exceptions that I do expect and can handle, and there are ones I do not and can't handle.
The same is probably true of most Error types you encounter like IOError could just be a folder can't be found and I can handle that by prompting the user, or it could be something else that is unexpected and I don't have a way to handle.
I think you might just want to change how you write your code a bit. A big part of writing in python is it is better to try and ask for forgiveness.
With this in mind, the way I write code is to write if for instance it was to check some data and run an insert query into multiple places, is to write one function that does everything linearly in the perfect case scenario, and then another function that does the try and except.
def createRecord(data):
if data['moneyAmount'] < 0:
raise FormError("Money amount can't be less than zero")
if data['someOtherKey'] == 1:
data['modifiedKey'] = 'newValue'
system.db.runNamedQuery("someForm", data)
def callingFunction(data):
try:
createRecord(data)
except FormError, e:
expectedError=True
# do something with this
except KeyError, e:
# Do something else with this
except java.Lang.Exception, e:
# do something iwth this
except Exception, e:
# log and abort
finally:
# Clean up /reset if neede based on if you got a expected or unexpected error
Like all hooks on the user side, we don’t need to define them until we use them 