你最喜欢的Grails调试技巧是什么？ [英] What are your favorite Grails debugging tricks?

问题描述

Grails可以使用它的长堆栈转储来调试它。了解问题的根源可能是棘手的。例如，在BootStrap.groovy中做了def foo = new Foo（a：a，b：b）.save（），我已经烧了几次。你最喜欢的调试Grails应用程序的技巧是什么？

Grails can be a bit of a bear to debug with its long stack dumps. Getting to the source of the problem can be tricky. I've gotten burned a few times in the BootStrap.groovy doing "def foo = new Foo(a: a, b: b).save()", for example. What are your favorite tricks for debugging Grails apps?

推荐答案

一些一般提示：

• 清除stacktrace.log，执行grails run-app，然后在查看器中打开stacktrace.log（我更喜欢 less stacktrace.log 在linux上）...一次在你的浏览器中，搜索.groovy和.gsp ...通常会带给你真正的关心。
  


• 当一个堆栈跟踪指的是GSP文件中的行号，您应该在查询字符串中的？showSource 的浏览器中打开该视图，即 http：// localhost：8080 / myProject / myController / myAction？showSource ...这显示了编译的GSP源，stacktrace中的所有GSP行号都是指编译的GSP，而不是实际的GSP源。 >


• 始终始终围绕您的保存至少有一些最小的错误处理。

• Clear stacktrace.log, do grails run-app, then open stacktrace.log in a viewer (I prefer less stacktrace.log on linux)... once in your viewer, search for .groovy and .gsp... that generally brings you to what you actually care about.
  
• When a stacktrace refers to a line number in a GSP file, you should open that view in a browser with ?showSource in the query string, i.e. http://localhost:8080/myProject/myController/myAction?showSource... this shows the compiled GSP source, and all GSP line numbers in the stacktrace refer to the compiled GSP, not the actual GSP source
  
• Always, always, always surround your saves with at least some minimal error handling.

示例：

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在它给你的错误消息中是非常无益的，但你可以学习识别模式，如下所示：

Beyond that, a lot of it just comes down to recognizing stacktraces and error messages... a lot of the time, Grails is incredibly unhelpful in the error messages it gives you, but you can learn to recognize patterns, like the following:

• 有意义的一些最难的错误是因为您没有运行 grails clean 或 grails升级 ...为了避免这些问题，我总是在命令行中使用以下命令来运行grails： grails clean ;是| grails升级; grails run-app



• 如果错误与类的重复定义有关，请确保您声明该类所属的包在类的文件的顶部


• 如果错误与架构元数据，连接，套接字或类似的东西有关，请确保您的数据库连接器在 lib / ，请确保您的权限在 DataSource.groovy 中以及用户名，密码和主机的数据库中都是正确的，并确保您知道连接器版本的内容（即，mysql连接器版本5.1.X有一个奇怪的问题，可能需要您设置 useOldAliasMetadataBehavior = true 在 DataSource.groovy 中的url上）

• Some of the hardest errors to make sense of are because you didn't run grails clean or grails upgrade... to avoid these problems, I always use the following on the command line to run grails: grails clean; yes | grails upgrade; grails run-app
  
• If the error has to do with duplicate definitions of a class, make sure that you declare the package the class belongs to at the top of the class's file
  
• If the error has to do with schema metadata, connection, socket, or anything like that, make sure your database connector is in lib/, make sure your permissions are correct both in DataSource.groovy and in the database for username, password, and host, and make sure that you know the ins and outs of your connector's version (i.e. mysql connector version 5.1.X has a weird issue with aliases that may require you to set useOldAliasMetadataBehavior=true on the url in DataSource.groovy)
  

等等上。有很多模式可以学习识别。

And so on. There are a lot of patterns to learn to recognize.

这篇关于你最喜欢的Grails调试技巧是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！