Project

General

Profile

Actions
Copy link

Bug #66411

closed

New locking API exceptions too generic

Added by Mathias Brodala about 9 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Must have
Assignee:
Mathias Brodala
Category:
Miscellaneous
Target version:
7.2 (Frontend)
Start date:
2015-04-14
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
7
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:
Stabilization Sprint

Description

The new locking API currently only uses RuntimeException to hint at errors during lock acquisition.

While this already has the disadvantage of catching other @RuntimeException@s the issue becomes rather clear with the non-blocking example:

try {
  $result = $locker->acquire(LockingStrategyInterface::LOCK_CAPABILITY_SHARED | LockingStrategyInterface::LOCK_CAPABILITY_NOBLOCK);
catch (\RuntimeException $e) {
  if ($e->getCode() === 1428700748) {
    // some process owns the lock, let's do something else meanwhile
  }
}

This requires knowing about this special case and knowing the magic number here. A dedicated exception would make this clearer.

Related issues 1 (0 open — 1 closed)

Follows TYPO3 Core - Feature #47712: Refactor LockingClosedMarkus Klein2013-02-08

Actions
Actions
Copy link

Also available in: Atom PDF