总是对这个问题感兴趣。这是一种可能发生已检查异常的方法。我们可以直接在方法内部处理它，也可以在上面转发它。我总是随机做的，就是我会在某处转发，我会在某处处理。但是由于某种原因，似乎总是如果这个方法很小，那么最好抛出异常。或者如果此方法不调用其他方法，而只是执行一些操作。从这一切中，我有一个问题，但是对于何时抛出异常以及何时处理它有什么标准吗？只是，其实异常可以通过这种方式抛出到main方法中。那么，如何判断上面什么时候抛出异常，什么时候处理呢？
我在第一次了解 DAO 层时遇到了这个问题，其中一个人强烈建议不要做具体的实现，而是通过接口编程。然而，随着时间的推移，问题出现了：为什么？可能所有的 DAO 类都不会改变，因此为每个类创建个人界面是没有意义的。即使 DBMS 本身发生变化，您也只需稍微更改查询语法。这就是新闻……这不仅发生在 DAO 中。当然，每个人都已经看到，人们不仅创建了一个类（例如）ConnectHelper，还创建了一个接口ConnectHelper，然后按类型实现了它ConnectHelperImpl. 同时，您很可能永远不必创建另一个实现此接口的类。因此，这对我来说是完全无法理解的——这是规范还是人们试图使他们的代码如此灵活以至于最终它是有害的并且使代码混乱？
维基百科以黑白方式说：
实体 - 使用 (@Entity) 注释或通过 XML 与数据库关联的 POJO 类。
但是，查看 POJO 类的细节，我了解到它不应该：
- 扩展预定义的类。
- 实现预定义的接口。
- 包含预定义的注释。
但是，在同一个 Wikipedia 上写到 Entity 类可以被继承、实现接口和使用注释。那么，这是否意味着 Entity 类必须是 POJO 才能成为实体？还是我不明白什么？
观看有关 Hibernate 的旧视频和文章，我发现他们的示例中的所有实体都实现了 Serializable 接口。视频中的一个人甚至说，没有这个，hibernate 会失败，因为实际上传输到数据库意味着序列化。问题的关键在于，现在我看到的所有例子中，没有人在Entity类中实现这个接口，我也不例外。同时，hibernate 为自己安静地工作，不会抱怨任何事情。那么，Entity 类是否需要实现这个接口，或者这是过去的遗物？
有两个实体：User和Address。在我的例子中，它们必须通过一对一的关系连接，也就是说，它们中的一个必须包含到另一个的链接：要么类User必须有一个Address address我们写入的字段@JoinColumn，并且从地址端我们做mappedBy，或者在类Addressa字段中User user我们也这样做。那么，如何准确地确定具有单向连接的哪个实体明显依赖于另一个实体，而哪个实体不应该知道它与它的连接呢？
在一篇关于 Hibernate 的文章中，我读到如果你想使用多线程，那么为每个 CRUD 操作创建一个新会话。也就是说，例如，我的 DAO 类中的保存操作如下所示：
public void save(User user) {
try (Session session = HibernateSessionFactoryUtil.getSessionFactory().openSession()) {
Transaction tx = session.beginTransaction();
session.save(user);
tx.commit();
}
}
但这就是问题所在。今天我看到另一篇文章说上面描述的动作是一种反模式。逐字：
这是一种关于在一个线程中打开和关闭对数据库的每个操作的 Session 对象的反模式。就数据库事务而言，这也是一种反模式。将您的呼叫分组到一个预定的序列中。此外，不要在每个 SQL 语句上自动提交事务。Hibernate 关闭，或期望应用程序服务器立即关闭自动提交模式。
相反，这篇文章建议Паттерн сессия-на-запрос，它被描述为：
最常见的交易模式。这里的术语“请求”应该在系统响应来自用户/客户端的一系列请求的上下文中理解。Web 应用程序是此类系统的主要示例，但它们当然不是唯一的。在请求处理开始时，应用程序打开一个 Session 对象，启动一个事务，执行所有与数据相关的工作，完成事务，并关闭 Session。该模式的本质是事务和会话之间的一对一关系。
在那之后，我出现了认知失调。首先，因为事实证明，根据这篇文章，我以前做错了，为每个操作创建一个会话，其次，因为我不明白第二种模式的含义。解释哪个是真的，哪个是假的。使用什么，忘记什么？
无论我在 Java 中看到多少带有日期的示例和字段，它们总是（或几乎总是）使用Date. 话虽这么说，我想每个人都知道这个类Date本身很糟糕：它不是线程安全的，也不代表它的名字所指示的内容（我们得到的是日期时间而不是日期）。同时，类LocalDate和LocalDateTime完全LocalTime覆盖了这些缺点，一般使用起来更方便。问题出现了，为什么人们仍然（而且不是无论如何，但即使在一些官方文档中也是如此）使用该类Date？
解决一个简单的任务，我遇到了方法引发异常的情况，我需要处理它。
public static void main(String[] args) {
String time = "10:15:30 PM";
String result = null;
try {
result = timeFormation(time);
}
catch(ParseException ex) {
ex.printStackTrace();
}
if(result != null && !result.equals(""))
System.out.println("Result is: " + result);
}
static String timeFormation(String time) throws ParseException {
SimpleDateFormat dateFormatter = new SimpleDateFormat("HH:mm:ss");
SimpleDateFormat parseFormatter = new SimpleDateFormat("hh:mm:ss a");
Date date = parseFormatter.parse(time);
return dateFormatter.format(date);
}
例外我不是特别强，不知道能不能做得更漂亮？让我感到困惑的是，我们必须创建一个新对象String = null，try-catch然后还要对其进行全面检查。这是正确的还是有更好的方法？并且，借此机会，我将提出一个问题：throws在帮助的情况下在方法中发出可能的异常信号是否正确，还是在方法中立即处理它们更好？