debugging - 您最喜欢的 Grails 调试技巧是什么？

Question

就目前情况而言，这个问题不太适合我们的问答形式。我们希望答案得到事实、引用资料或专业知识的支持，但这个问题可能会引发辩论、争论、民意调查或扩展讨论。如果您觉得这个问题可以改进并可能重新开放， visit the help center以获得指导。

已关闭 11 年前。

Grails 的长堆栈转储可能有点难以调试。找出问题的根源可能很棘手。例如，我在 BootStrap.groovy 中执行“def foo = new Foo(a: a, b: b).save()”时被烧伤了几次。您最喜欢的调试 Grails 应用程序的技巧是什么？

Answer 1

一些一般提示:

• 清除 stacktrace.log，执行 grails run-app，然后在查看器中打开 stacktrace.log(我更喜欢在 Linux 上使用 less stacktrace.log)...在查看器中搜索 . groovy 和 .gsp...通常会带您了解您真正关心的内容。
  
• 当堆栈跟踪引用 GSP 文件中的行号时，您应该在浏览器中在查询字符串中使用 ?showSource 打开该 View ，即 http://localhost:8080/myProject/myController/myAction?showSource...这显示了已编译的 GSP 源代码，堆栈跟踪中的所有 GSP 行号均指已编译的 GSP，而不是实际的 GSP 源
  
• 始终、始终、始终在您的保存周围至少进行一些最小的错误处理。

示例:

try {
    if(!someDomainObject.save()) {
        throw new Exception ("Save failed")
    } 
} catch(Exception e) {
    println e.toString()
    // This will at least tell you what is wrong with
    // the instance you are trying to save
    someDomainObject.errors.allErrors.each {error ->
        println error.toString()
    }
}

除此之外，很多事情只是归结为识别堆栈跟踪和错误消息...很多时候，Grails 在提供给您的错误消息中毫无帮助，但是您可以学习识别模式，例如以下:

• 一些最难理解的错误是因为您没有运行 grails clean 或 grails Upgrade...为了避免这些问题，我总是使用在命令行上运行 grails:grails clean;是的 | Grails 升级； grails run-app
  
• 如果错误与类的重复定义有关，请确保在类文件的顶部声明该类所属的包
  
• 如果错误与架构元数据、连接、套接字或类似内容有关，请确保您的数据库连接器位于 lib/ 中，并确保您的权限在 中均正确DataSource.groovy 并在数据库中查找用户名、密码和主机，并确保您了解连接器版本的详细信息(即 mysql 连接器版本 5.1.X 有一个奇怪的别名问题，可能需要您可以在 DataSource.groovy 中的网址上设置 useOldAliasMetadataBehavior=true)
  

等等。有很多模式需要学习识别。