创建一个文件并用一个线程填充它后,如果文件在USB中,则java无法删除它,当我在磁盘上尝试删除文件时就OK了!
以下是在尝试删除文件时创建和执行异常后的代码部分。
if(canExport && fileCreated)
{
//Create the file
this.file.createNewFile();
//Export the data
this.run();
if(possible == false){ // in case writing fails delete the file created.
file.delete();
Export novaTentativa = new Export(plan);
novaTentativa.fileCreator(plan);
}
}
当this.file.createNewFile()动作时创建文件。
当 this.run()运行时,有很多方法可以填充数据和处理异常,如果发现一个异常,它会设置全局变量可能为false因此我知道文件已创建但在USB中为空,之后我尝试用file.delete()删除它;
答案 0 :(得分:2)
你提到你试图在“异常后”删除文件 - 因此,你的方法是在错误的轨道上,并且不会按原样运作。
如果早期方法(例如createNewFile()
调用)抛出异常,则该异常将立即向上传播,因此您的file.delete()
调用将无法执行。您需要将先前的语句包装在try
块中,并将删除调用放在相应的catch
或finally
块中,以便在抛出异常时执行。
以下是您可能尝试做的一个示例:
if(canExport && fileCreated)
{
//Create the file
this.file.createNewFile();
try
{
this.run();
}
catch (IOException e)
{
try
{
file.delete();
}
catch (IOException ignore) {} // don't want to mask the real exception
// Rethrow the actual exception from run() so callers can handle it
throw e;
}
}
替代方法而不是捕获IOExceptions
将是finally
块(始终运行),然后检查那里的条件,例如possible
标志。
请注意,在调用createNewFile()
之后,我启动了try块 - 如果在create file调用中抛出异常,那么该文件根本不会被删除!
作为文件说明,在错误处理块中添加“许多要求重新启动线程的代码”可能不是最好的设计。在这里简单地考虑从IO情况中恢复是更合适的,并且让异常气泡到顶部并导致线程/ runnable死亡。关于重新启动任务和/或恢复线程的逻辑将更好地定位在首先启动线程的类(例如线程池/任务执行器/等)。在整个代码中分散逻辑将使得更难以看到任何单个类正在做什么(更不用说有一个类marshall资源来复活本身从OO的角度来看似乎是错误的。)
答案 1 :(得分:0)
尝试明确说明驱动器号,路径和文件夹以访问USB设备以创建写入和读取或删除文件。如果这不起作用,那么只有特定的操作系统实用程序或专有实用程序才能删除该文件。
答案 2 :(得分:0)
当写入失败时,您关闭文件有多确定?我敢打赌你在this.run()的某个地方错过了一个终结块。这将导致您描述的行为 - 如果文件打开,delete()将失败(您应该检查它的返回代码 - 如果无法删除文件,File.delete()不会抛出异常)。 p>
如果你想测试这个,用一个超级,疯狂的简单实现替换this.run(),该实现将100个字节写入文件,将'possible'设置为false,然后返回。如果文件仍然不会被删除,请发布您正在使用的代码用于run()的简化版本,也许有人可以发现正在发生的事情。