Bug #101929
closed
ViewHelperInvoker should catch Exceptions allow the Site-Developer to handle or supress exceptions
0%
Description
The ViewHelperInvoker (\TYPO3Fluid\Fluid\Core\ViewHelper\ViewHelperInvoker) should catch Exceptions allow the Site-Developer to handle or supress exceptions. This can be useful to supress exceptions for f.e. missing images, FAL, files (f:image etc.).
To archive that the ViewHelperInvoker should emit a Signal that developers can use to receive such Error-Events and giving them the ability to supress the actual Exception or implement custom rendering to replace the output of ViewHelpers.
So far I've extended/wrapped such core-viewhelpers to implement a more user-friendly handling of minor errors (like missing image or download files), replacing them with log-signal, user-friendly error-message, placeholder image and so on. This enshures the rest of the website works even if there is a stupid image missing.
This is not possible anymore due to the breaking change, that most of these ViewHelpers are now declared final class. Site-Developers would have to maintain their 1:1 copy of these core-classes (instead of simply extending the logic). This isn't useful as this could also lead to core-fixes that won't apply there anymore.
So I think there must be a better solution to give developers the ability to handle this themselfe -- or keep the old Exception if they don't care about it.
I think at least implementing a signal-event should be no brain-breaker!
Updated by Gabriel Kaufmann / Typoworx NewMedia 10 months ago
- Related to Bug #101927: TYPO3 Fluid Core ViewHelpers should not be declared "final class" added
Updated by Gabriel Kaufmann / Typoworx NewMedia 10 months ago
- Related to Bug #101928: f:image(.uri) and other FAL/File ViewHelpers should never raise an Exception for missing files! added
Updated by Gabriel Kaufmann / Typoworx NewMedia 10 months ago
- Related to Task #95298: ViewHelpers will be declared final in v12 added
Updated by Claus Due 9 months ago
Error handling in Fluid is possible via the ErrorHandler concept - which you can replace by setting a custom implementation into the RenderingContext. See \TYPO3Fluid\Fluid\Core\ErrorHandler\ErrorHandlerInterface and \TYPO3Fluid\Fluid\Core\Rendering\RenderingContextInterface::setErrorHandler.
Alternative methods also exist, e.g. the VHS extension has counterparts for image rendering which all provide a "graceful" boolean argument to suppress re-throwing of exceptions. Or v:try which lets you trigger other processing (default image for example) when such exceptions are raised.
Updated by Why Fullname 3 days ago
ยท Edited
Agree 100%, its a no Brainer for Stuff like this. Catch Exception and Syslog or no Exception. Any news on this it seems like this is still the same exception handling? Just updated to Typo3 12 and the first Exception ImageViewHelper is final :D
Back then i just commented these useless Typo3 Exception of ImageViewHelper out and Frontend works fine. Why is Typo3 always making me wanting to quit development.
Now with Composer its easier to override the typo3 code changes and with final ImageViewHelper you cant even override it anymore, why? there is not a single reason for making it final. I think to relate on a external extension is bad.
And ErrorHandler should be for Errors and not fixing Bad Design or Bugs inside Typo Code.
Updated by Garvin Hicking 3 days ago
- Status changed from New to Closed
Hi Why Fullname,
the issue tracker is not a suitable place to have discussions about strategy. It can be adressed with constructive feedback on talk.typo3.org, after which we can draft possible solutions and maybe adress this with a follow-up.
I will close this issue for now as I believe this will not be productive here. I hope you understand and I am looking forward to a proper, unheated and civil discussion :-)
Thanks,
Garvin