K
K
Kirill Tekord2016-10-29 15:39:08
Yii
Kirill Tekord, 2016-10-29 15:39:08

When should you trigger events BEFORE and AFTER some irreversible action?

The user initiates an irreversible action - deleting his account from the site. The user is prompted to fill out a form indicating the reason for deletion, the site owner needs this for analytics. If the user fills in the form correctly, the program creates a transaction from the following commands:
1. Delete the user's account entry from the database;
2. Save the data from the form about the reasons for deleting the account in the database.
Before the transaction is executed, the EVENT_BEFORE_REMOVE event is triggered. Event subscribers can change something in the initial data, for example, add some service data to the account deletion reason form or filter the data. Since at this stage a change (filtering) and / or addition of the initial data is expected, the call of the EVENT_BEFORE_REMOVE event handlers should be wrapped in try / catch and if something bad happens to the subscribers, then we cancel the transaction and show the error to the user.
Sample code:

try {
  $userAccount->trigger(UserAccount::EVENT_BEFORE_REMOVE);

  $userAccount->delete();
  $reasonForm->save();

  $transaction->commit();
}
catch (\Exception $e) {
   $transaction->rollback();

   throw $e;
}

Now question #1 : where should the EVENT_ AFTER _REMOVE event be triggered? Immediately after the commit of the transaction, inside the try/catch block, or after this block, because the main work has already been done ? Loggers and various analytical modules will be subscribed to the EVENT_ AFTER
_REMOVE event , which will change the counter of the number of remote users and the total number of users. Obviously, subscribers to this event will no longer be able to influence the outcome of deleting an account, it has already been deleted, and updating counters is not such an important procedure. Question #2 :
is it worth wrapping the EVENT_AFTER_REMOVE event trigger in a try/catch block, and write errors to the log in catch in silent mode without showing errors to users? Or is it better to require subscribers to control and log their own mistakes ?
In the first case, if an error occurs in one handler, the execution sequence is interrupted. In the second case, subscribers with errors are skipped and subsequent ones are executed, but more checks should be required from subscribers.

Answer the question

In order to leave comments, you need to log in

1 answer(s)
M
Maxim Fedorov, 2016-10-31
@tekord

1. The generation of the EVENT_AFTER_REMOVE event should be placed immediately after the commit. If you place the generation after the try / catch block, a situation may arise when some kind of exception occurred during the deletion process, you caught it and rolled back the transaction. Those. deletion did not actually happen, and the event will be generated - this is not entirely correct
2. Not worth it, subscribers must handle errors themselves

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question