Uncaught exception for removed files about flux HOT 16 CLOSED

Agree. And might I add: damn you, FAL, for throwing an exception instead of returning NULL in so many unnecessary cases.

from flux.

Ah, FAL again. Anything you/we can do here on our side?

from flux.

Anything you/we can do here on our side?

Let's find out :)

from flux.

Moving files via fileadmin leads to the same exception. I thought that's what FAL is all about...?

from flux.

I thought that's what FAL is all about...?

Beats me. The most I've gotten out of it so far is new Exception types in new and exciting places.

from flux.

This particular exception is thrown after getSingleField_typeFlex_draw() is invoked in the override class. Could be caught there of course, but what then? And do you think it is worth the effort to check which exceptions might be raised as well to create a plan? Questions for the weekend ;)

from flux.

I think the fix will probably confuse a bit, but it's certainly better than an uncaught exception. We can wrap \TYPO3\CMS\Backend\Form\FormEngine::getSingleField_SW and catch this particular type of exception, if caught we can attempt to fix the field value before attempting re-render.

Ugly.

from flux.

Does the Exception by any chance contain a property with the name of the file...?

from flux.

Only in the exception trace. It's a dumb exception :\

from flux.

I think I have a solution for it - but it's not pretty; it removes the entire value if a FileNotFoundException is encountered. It's better than the Exception, but still not a very friendly thing to do. I was hoping for a way to detect the individual file that's failing and only remove it :/

from flux.

How is this one treating you, Björn? Too drastic...?

from flux.

The current behavior without your patch is too drastic =) I think this is an edge case and FluidTYPO3 can't save the world so I'm fine with this.

from flux.

Perhaps one last thing. Adding a FlashMessage when this happens, including a dump of the old field value.

from flux.

Sure, even better. In the end it's a user's fault that raises the exception but this way she knows why.

from flux.

In the end it's a user's fault

I actually blame FAL - those references should be stored and warned about when removing FAL files; they are in other contexts. But then again, this reference being inside a FlexForm does relieve them of a small part of that blame :)

from flux.

Closing this one - solved by the merged PR :)

from flux.