From 0fd773a486fbc1aeef7f00ec5eab3eaf0e4c6a9d Mon Sep 17 00:00:00 2001 From: Goffin Simon Date: Thu, 18 Dec 2014 16:38:09 +0100 Subject: [IMP] Cleanup and refactoring of exception handling Unify and refactor exception handling in framework and addons. The generic `except_osv` is now deprecated, and replaced by more specialized exception subtypes: - `UserError` (renamed from Warning, as it conflicts with the built-in `Warning`) raised when a non-technical error occurs during a business operation. It could be a missing information in the data provided by the user, or a misconfiguration. - `AccessError`: raised when any operation is denied because the user conducting it does not have the required access rights. - `AccessDenied`: raised when an operation that requires authenticated access is attempted via an unauthenticated request. - `MissingError`: raised when an operation is attempted on a record that does not exist. - `ValidationError`: raised when an operation violates a SQL or Python constraint. - All other exceptions are internal errors due to a system problem or bug, and raised untouched to the client-side, which should display a traceback. All exceptions take a single message argument. The `test_exceptions` module has been updated to showcase both new and old (deprecated) exceptions. A great many old `except_osv` had a useless title with "Error!" or "Warning", those have been removed, as this is handled by the client-side widget that displays the messages. This commit introduces a more consistent policy for logging errors and warnings: - All messages that do not require administrator attention should be logged at INFO level or lower. This includes all errors that are notified to the user in a friendly manner, even for access right problems or validation errors during business operations. - All messages that indicate a likely misconfiguration or malicious use by the users should be logged at WARNING level, as they typically require administrator attention. - All other unhandled internal errors cannot typically be handled by the user and should be logged at ERROR or higher level, as they require immediate administrator attention. --- addons/analytic_user_function/analytic_user_function.py | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) (limited to 'addons/analytic_user_function') diff --git a/addons/analytic_user_function/analytic_user_function.py b/addons/analytic_user_function/analytic_user_function.py index 4337e7a72e2..855ee4ced47 100644 --- a/addons/analytic_user_function/analytic_user_function.py +++ b/addons/analytic_user_function/analytic_user_function.py @@ -22,6 +22,7 @@ from openerp.osv import fields,osv from openerp.tools.translate import _ import openerp.addons.decimal_precision as dp +from openerp.exceptions import UserError class analytic_user_funct_grid(osv.osv): _name="analytic.user.funct.grid" @@ -105,10 +106,7 @@ class hr_analytic_timesheet(osv.osv): if not a: a = r.product_id.categ_id.property_account_expense_categ.id if not a: - raise osv.except_osv(_('Error!'), - _('There is no expense account defined ' \ - 'for this product: "%s" (id:%d)') % \ - (r.product_id.name, r.product_id.id,)) + raise UserError(_('There is no expense account defined for this product: "%s" (id:%d)') % (r.product_id.name, r.product_id.id,)) # Compute based on pricetype if unit_amount: amount_unit = self.on_change_unit_amount(cr, uid, ids, @@ -134,7 +132,7 @@ class hr_analytic_timesheet(osv.osv): if not a: a = r.product_id.categ_id.property_account_expense_categ.id if not a: - raise osv.except_osv(_('Error!'), + raise UserError( _('There is no expense account defined ' \ 'for this product: "%s" (id:%d)') % \ (r.product_id.name, r.product_id.id,)) -- cgit v1.2.3