[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.

1 files changed, 3 insertions, 4 deletions

diff --git a/addons/mail/tests/test_mail_group.py b/addons/mail/tests/test_mail_group.py
index c131ce0bd0b..25a4d5b199e 100644
--- a/addons/mail/tests/test_mail_group.py
+++ b/addons/mail/tests/test_mail_group.py
@@ -21,7 +21,6 @@
 
 from openerp.addons.mail.tests.common import TestMail
 from openerp.exceptions import AccessError
-from openerp.osv.orm import except_orm
 from openerp.tools import mute_logger
 
 
@@ -35,7 +34,7 @@ class TestMailGroup(TestMail):
         # Do: Bert reads Jobs -> ok, public
         self.mail_group.read(cr, user_noone_id, [self.group_jobs_id])
         # Do: Bert read Pigs -> ko, restricted to employees
-        with self.assertRaises(except_orm):
+        with self.assertRaises(AccessError):
             self.mail_group.read(cr, user_noone_id, [self.group_pigs_id])
         # Do: Raoul read Pigs -> ok, belong to employees
         self.mail_group.read(cr, user_employee_id, [self.group_pigs_id])
@@ -50,7 +49,7 @@ class TestMailGroup(TestMail):
         self.mail_group.read(cr, user_noone_id, [new_group_id])
 
         # Do: Raoul reads Priv -> ko, private
-        with self.assertRaises(except_orm):
+        with self.assertRaises(AccessError):
             self.mail_group.read(cr, user_employee_id, [self.group_priv_id])
         # Do: Raoul added in follower, read -> ok, in followers
         self.mail_group.message_subscribe_users(cr, uid, [self.group_priv_id], [user_employee_id])
@@ -62,7 +61,7 @@ class TestMailGroup(TestMail):
         with self.assertRaises(AccessError):
             self.mail_group.write(cr, user_noone_id, [self.group_priv_id], {'name': 're-modified'})
         # Test: Bert cannot unlink the group
-        with self.assertRaises(except_orm):
+        with self.assertRaises(AccessError):
             self.mail_group.unlink(cr, user_noone_id, [self.group_priv_id])
         # Do: Raoul unlinks the group, there are no followers and messages left
         self.mail_group.unlink(cr, user_employee_id, [self.group_priv_id])