3

关于潜在的运行时故障，如数据库查询，似乎必须使用某种形式的Either[String, Option[T]]才能准确捕获以下结果：

  1. 一些（找到的记录）
  2. 无（未找到记录）
  3. SQL 异常

选项根本没有足够的选项。

我想我需要深入研究 scalaz，但现在它是直接的，除非我在上面遗漏了一些东西。

我的 DAO 实现让自己陷入了困境，只使用 Either 进行写入操作，但现在我看到一些 Either 写入依赖于 Option 读取（例如检查新用户注册时是否存在电子邮件），这是一个非常糟糕的赌博.

在我全力以赴之前，是否有人有替代解决方案来处理成功/失败/异常的运行时三重奏？

4

3 回答 3

8

Box从奇妙的lift框架中尝试。它提供了你想要的。

有关详细信息，请参阅此 wiki（以及顶部的链接）。幸运的是，电梯项目被很好地模块化，唯一要使用的依赖项Box是net.lift-web % lift-common

于 2012-07-15T00:48:39.760 回答
5

Option[T]在 SQLException 的情况下使用records found并no records found抛出异常。

只需将异常包装在您自己的异常类型中，PersistenceException这样您就不会有泄漏的抽象。

我们这样做是因为我们不能也不想从意外的数据库异常中恢复。异常在顶层被捕获，我们的 Web 服务500 Internal server error在这种情况下返回 a。

在我们想要恢复的情况下，我们使用Validationscalaz，这很像 Lift 的Box.

于 2012-07-15T17:16:13.617 回答
0

这是我修改后的方法

保留返回查询写入操作（对于我们想要回滚以理解左结果的事务块很有用）。

然而，对于返回查询读取的选项，我没有用 None 吞下异常（并记录它），而是创建了一个 500 错误屏幕，让异常冒泡。

在处理查询异常等运行时失败时，为什么不默认使用 Either 结果类型？使用 Option[T] 读取比使用 Either[Why-Fail, Option[T]] 更方便一些，您必须折叠/映射才能到达 T。离开 Either 来编写操作可以简化事情（更所以鉴于这就是应用程序当前的设置方式，不需要重构 ;-))

唯一需要的其他更改是针对 AJAX 请求。我们不是在 AJAX 状态 div 容器中显示整个 500 错误页面响应，而是检查状态类型并相应地显示 500 错误消息。

if(data.status == 500) 
  $('#status > div').html("an error occurred, please try again")

在发送响应之前可能会在服务器端进行 isAjax 检查；在这种情况下，我只能发回状态 + 消息而不是错误页面本身。

于 2012-07-16T15:45:10.280 回答