我正在创建一个命令处理库，它接受输入并在由于各种原因无法执行命令时抛出异常。我想向用户提供有关出错的有用信息，我也希望所有消息都可以自定义，以便可以在多个项目中使用。当我处理用户输入时，有一些愚蠢的事情可能会出错，并且为所有这些事件做一个例外会让我有更多的异常类而不是实际的命令处理类，所以我做了一些通用的例外：{{ 1}}和CommandException以及CommandUsageException扩展CommandPermissionException。
是否值得对例如CommandException或InvalidFlagValueException可能出错的所有内容进行例外处理，还是有更好的方法来执行此操作？例如，在例外中使用WrongSubcommandArgumentsException来提供更多细节是个好主意吗？
答案 0 :(得分：0)
我认为这是一个纯粹的设计决定。您可以映射出异常并使用它们构建继承树。或者您可以组合成广泛的异常，然后确保异常具有String参数，以便您可以输入消息。如果我是你，我会做后者并在const final变量中有消息。然后你可以从任何类访问它们，这样你就会有一些一致性。我也在这种情况下使用String.format
例如，String常量可能是
public static final String CANNOT_READ = "Cannot read string from %s";
然后在exeption中做
throws new MyException(String.format(CANNOT_READ, "file");
然后，您可以根据要拨打的班级将“文件”更改为您想要的任何内容。字符串常量为您提供了一些结构，但String.format为您提供了一些自定义。
答案 1 :(得分：0)
以这种方式考虑例外：
例如：如果你有函数/方法createFile，你可以有不同的例外NotEnoughSpace，NotEnoughPermissions，FileAlreadyExists - 所有这些都需要来自调用者的不同操作，它是有意识地抓住他们
InvalidFlag和WrongSubcommand的不同处理程序吗？我想两者都是语法致命错误，但是CommandPermission - 有些用户会有它，有些用户没有，有意义抛出它并以不同的方式处理它答案 2 :(得分：0)
是否值得对可能出错的所有内容进行异常，例如InvalidFlagValueException或WrongSubcommandArgumentsException，或者有更好的方法吗？
我回答这个问题的方法是试图弄清楚你是否需要单独捕捉这些例外情况;例如您曾编写明确捕获InvalidFlagValueException和WrongSubcommandArgumentsException的代码。
如果真的需要这样做，那么就有一个例外情况。
如果没有真正的需要（只有你可以判断），那么单独的异常类不会带来任何好处。
您可能已经发现可以通过向异常添加消息字符串，代码和其他信息来传递额外信息（并提供getter来检索它们）。
在例外中使用枚举来提供更多详细信息是否是一个好主意？
这很棘手。
一方面，enum是代码编号的干净替代品。
另一方面，enum类型不是动态可扩展的。
如果您有一个enum（例如）10个值，并且您想要添加第11个来表示新的错误条件，那么您有来更改源代码并重新编译enum条款。enum。幸运的是，枚举的二进制兼容性规则意味着您可以在不破坏兼容性的情况下添加和/或重新排序值。显然，但是：
使用这些值的任何代码都需要知道具体的代码，如果需要引用新的代码，则必须重新编译。
删除或重命名枚举值将破坏二进制兼容性。
您现在拥有一个“核心框架”类，可能需要在添加新命令时进行更改。如果命令是由第二方和第三方“可插拔”/编写的话，那就是一个问题。
但如果这些实际约束是可以接受的，那么使用{{1}}作为错误代码是合理的设计选择。