As I said, the file data was likely popped off the stack automatically, no need to write any extra code.

In your model, what's happening to the data in the file system?

Uploads are often initially stored in a temp directory before they are validated and moved to wherever they are meant to be stored, and the default behavior in PHP, for example, is to delete uploads that are not moved or renamed at the end of the request.

In the scenario I'm describing nothing is ever written to disk. The uploaded image data is streamed into memory directly from the socket and is processed in situ, when an exception occurs the stack unwinds and deallocates the memory storing the image data.

Writing extra code to delete a file in a catch block doesn't seem like something someone trying to account for failure scenarios would do, it's much more likely that the data was living in memory and no thought was put into failure scenarios in that part of the code.

But it is incredibly unlikely that web uploads are piped directly into custom software rather than just being written as files which are processed later. That would be an extreme amount of extra work for no benefit at all.

Tomcat gives you a http request object where you can just grab the input stream object and pass it to pretty much every library that processes files because opening a file just gives you a fileinputstream so adding general support for inputstreams is much easier than actually adding support that only works on files.

It's not at all unlikely, this is the default behavior for various setups, e.g. nodejs with express which is primarily a streams based system where you'd have to do extra work to write to disk.

It was never on the file system (kept in RAM) or it was in some temporary folder where files get deleted when an upload request has finished processing the file to prevent DOS attacks. Automatically keeping uploaded files sounds like a really really bad idea.