[TYPO3-dev] Exceptions of LocalDriver in TYPO3 6.2.x and their consequences

Philipp Gampe philipp.gampe at typo3.org
Thu Oct 9 17:06:41 CEST 2014


Hi Frank,

Frank Gerards | FORMER03 GmbH wrote:

> Is there sth like a joint effort to fix this problems and - more important
> - communicate the handling of FAL resources

It is not even such simple things like a missing file that creates problems 
all over the place, but also things like offline storages, deleted but 
referenced storages, etc.

The whole concept is broken here (not FAL, but the frontend using FAL). 
AFAIK there is still not concept/documentation on how the typical usage flow 
of a frontend call to render a file should look like.
There is not documentation on who calls what at what point and how to react 
on errors, what to check before calling certain functions -
Not to talk about localization.
getXYZ() calls suddenly try to create folders in the middle of the call 
chain, because the try to fix things they should care about and completely 
ignore a readonly flag (processing folder creation on getRole).

There is no or little documentation (some PHPdoc, but most are useless) on 
how certain functions behave (e.g. ignore permissions, delete flags, etc).

There is no documentation on what functions are high level API (e.g. do 
everything for you; called porcelain commands in git) and what functions are 
the plumber commands, the kind of comments if you need to do tricky stuff.
There is no (public) concept off what to call in which situations.
There is no concept of what is a working, consistent state of a storage, 
when it is inconsistent or broken and who and what command are supposed to 
fix this and everything bring back to a consistent state. Currently it 
happens sometimes magically and something just not resulting to all sorts of 
exceptions. Partially exceptions are used as GOTO alternative, a pattern I 
come across regularly on OOP "experts" (nothing here GOTO main function IS 
the same is throwing an exception and catching it in the main function just 
to find out if a record exists or not; exceptions should be for exceptional 
conditions and not for regular program behavior and expected error 
conditions).

Because of this, some people - including me - fixed a few fatal errors they 
came across, but we can do little to mitigate the conceptual problems 
outlined above.
It is up the the main developers of FAL to provide a documentation on how it 
*should* behave, such that others can go ahead and fix bugs based on that.

Best regards
-- 
Philipp Gampe – PGP-Key 0AD96065 – TYPO3 UG Bonn/Köln
Documentation – Active contributor TYPO3 CMS
TYPO3 .... inspiring people to share!




More information about the TYPO3-dev mailing list