John Broglio

One thing I like about Groovy is the ease of accessing library calls. Examples from Groovy:
1. database. I can dynamically load the mysql jar, connect, and pose a query in 3 lines
2. http. I can make and process an http/https POST in a few lines (with the http-builder library)
3. mail. I can send mail in 2 lines (using AntBuilder and javamail)

In these and similar cases, how does Scala compare? I know I can drop through to Java libraries with both Groovy and Scala, but if I have to insert verbose Java-style library invocation repeatedly, that would pretty much defeat the purpose of having a succinct language.

Thanks,
John

This is one of the fundamental problems with checked exceptions in a lexically scoped world. Stan's advice is very useful and probably most often used.
But if you find yourself declaring "throws Exception" in your intermediate layers just to pass the exception from the bean to the client, you're probably just as well off using unchecked exceptions for this case: extend RuntimeException and put a note in your API documentation. Rod Johnson is very eloquent on this topic in his book, Expert one-on-one J2EE Design and Development). Logging the stacktrace from the bean/server reduces the necessity of serializing the stacktrace for the client.
Alternative B: for typical exceptions like "file not found" you can pass a "callback" argument to the bean with handlers for the typical exceptions (this works best when client and bean are on the same machine).
Alternative C: (like B but works across the net) make your return value a somewhat richer object {value, [exception, stacktrace], handler(clientObject)}. This allows you to propagate "warnings" as well, which the standard exception model does not. Your return object can be subclassed to add handlers for each case. When the client receives the return object it calls the return object's "handler" method (with the client itself as a parameter).
Alternative D: do everything you can to avoid propagating exceptions to the client. Except for a few obvious cases (misspelled file names, for example), most exceptions deep down in the server don't mean anything to the client. Better to log them on the server (as warnings) and factor your client code so that it knows how to handle the "null" return value intelligently. To continue with the file example: "File not found" is an exception to the server, but it's just information to the client (how often have you done a "dir" or "ls" to make sure that something you tried to delete actually did get deleted?). This should be Alternative A, but if your roundtrip cost is high, it becomes less attractive, since it may involve the client querying predicates on the bean/server either before or after the call to get more detailed information about possible failed calls.

Yes. You can find it at:
http://wwws.sun.com/software/communitysource/javawebstart/download.html
I think you need to be a Sun Java developer community member (no problem: membership is free and very useful).