2017-09-04 108 views
0

的方法返回部分不完整的结果,我想上的情况下的一些反馈:从抛出异常

的方法构造一个对象,但一些工作,同时构建它可能无法完成。这将导致缺少一些数据的对象。我想给这个方法的用户处理对象的能力(如果完成的话),但是如果不完整则处理对象,同时也能够处理抛出的异常。

使用案例:

我从磁盘读取一个文件到一个POJO和文件的一些属性,如创建可以抛出,而从操作系统中读取一个例外日期。在这种情况下,我抛出了一个自定义的异常,但我也希望用户能够处理不完整的文件表示(POJO)。

我的解决办法:

我用它包装抛出的异常和不完整的对象自定义异常。

我的代码:

public FileDto getFromFile(File f) throws IncompleteFileDtoException { 

    FileDto dto = new FileDto(); 
    dto.setName(f.getName()); 
    dto.setPath(f.getAbsolutePath()); 
    dto.setDirectory(f.isDirectory()); 
    dto.setSize(f.length()); 
    dto.setModifiedAt(f.lastModified()); 

    try { 
     BasicFileAttributes attr = Files.readAttributes(f.toPath(), BasicFileAttributes.class); 
     dto.setCreatedAt(attr.creationTime().toMillis()); 
    } 
    catch(Exception e) 
    { 
     throw new IncompleteFileDtoException("Unable to transform " +f.getAbsolutePath() + " to DTO.", e, dto); 
    } 
    return dto; 
} 

public static class IncompleteFileDtoException extends Exception 
{ 
    private FileDto fileDto; 

    public IncompleteFileDtoException(String message, Exception e, FileDto fileDto) 
    { 
     super(message,e); 
     this.fileDto = fileDto; 
    } 

    public FileDto getFileDto() { 
     return fileDto; 
    } 
} 

会这样的代码有什么负面影响?

回答

0

我为您提供使用Builder模式。请创建FileDtoBuilder并将其置入异常。当您成功读取文件时,会从现有的FileDtoBuilder创建FileDto实例。

四人帮设计模式 https://en.wikipedia.org/wiki/Builder_pattern

+0

这听起来确实是一个有趣的补充。我能从中看到的一个好处是,Builder将对象构造过程(可能很重)委托给方法的用户,如果认为它不是必要的,他不会构造对象并且不会使用资源,对吗? –

+0

这是正确的。它在很多情况下非常有用:例如像你的,当你在对象初始化过程中遇到问题时,或者当你想用许多最终参数来构建不可修改的对象时(而不是使用具有所有这些参数的构造函数)。 “四人帮”是关于它的很好的书。 –

0

你举的例子仅包含一个值,它可能会导致一个问题,但只要你有你结束了安静的复杂代码的多个值,因为你要不断该信息是否应该引发这样的例外。

就个人而言,如果处理失败,但是对于该特定值的初始化,则更好的方法可能是设置适合的默认值(如果不是空值)。如果某个值可以为null,那么您可以执行整个异常抛出。如果您需要知道安装过程中是否出现问题,请在该对象中添加一个标志,以便在出现可能会失败的情况时提供信息。这也可以让你传递物体而不会丢失后续课程中的信息等。

简而言之:例外应该只指示例外情况,即不能使用对象而不是表示预期的情况

+0

https://gist.github.com/ipapaste/d7350cd071e72ab01800b8b0d076c8cc 我想这会更好吗?我正在下沉这个异常,而是用关于它的创建的元数据返回对象的结果包装。 –