Question

I’m trying to create an automated error reporting tool for our Java desktop app. the idea is to make it as easy as possible for customers to send us error reports whenever our application crashes.

Using the Desktop.mail API, I am able to craft messages that can be easily edited and sent from our users, but I’m running into system limitations on several platforms (notably Windows 7 and MS Outlook, which most customers are using)

When I run the example code below, you’ll notice that the email message that is displayed truncates the included stack trace. I believe this has something to do with a maximum length of either command lines or URIs in the underlying systems.

Is there a better way to craft an email from an error report that is not subject to this limitation?

import java.awt.Desktop;
import java.io.PrintWriter;
import java.io.StringWriter;
import java.net.URI;
import java.net.URLEncoder;

public class Scratchpad {

    public static void main(String[] args) throws Exception {
        try {
            generateLongStackTrace();
        } catch (Error e) {
            URI uri = createMailURI(e);
            // this will correctly pop up the system email client, but it will truncate the message
            // after about 2K of data (this seems system dependent)
            Desktop.getDesktop().mail(uri);
        }
    }

    // Will eventually generate a really long stack overflow error
    public static void generateLongStackTrace() throws Exception {
        generateLongStackTrace();
    }

    public static URI createMailURI(Error e) throws Exception {
        StringBuilder builder = new StringBuilder();
        builder.append("mailto:[e-mail]?body=");
        // encodes the stack trace in a mailto URI friendly form
        String encodedStackTrace = URLEncoder.encode(dumpToString(e), "utf-8").replace("+", "%20");
        builder.append(encodedStackTrace);
        return new URI(builder.toString());
    }

    // Dumps the offending stack trace into a string object.
    public static String dumpToString(Error e) {
        StringWriter sWriter = new StringWriter();
        PrintWriter writer = new PrintWriter(sWriter);
        e.printStackTrace(writer);
        writer.flush();
        return sWriter.toString();
    }

}

Answer 1

there are length limitations wrt admissible urls in ie and the length of a windows command line (see here, here, here and here) – i seems you run into one of these (though i admit that i have not rigorously checked).
however i think it’s a plausible assumption that even if you could worm your way around the said limits the length of a generic transmission buffer between desktop applications (unless you use a dedicated api for remote controlling the target app) will be restricted somehow without a loophole.

therefore i’d suggest one of the following strategies:

1. distribution through a web server.

   • upload the data to be mailed to a web server instead using the html form file upload technique.
     basically you have to forge a POST request a payload with content type set to ‘multipart/form-data’. your content will need some wrapper data to conform syntactically with this mime type.
   • the actual transmission can be instigated by means of the WinHttpRequest COM object under windows or the curl command line program from everywhere else.
   • server side processing can be delegated to a suitable cgi handler which eg. might produce a (short) link to download the data fom the web server.
   • this link may be part of the http response to the upload request or you generate it client-side in the proper format for publishing it on the web server unaltered.
   • pro:
     this scheme is feasible – i have repeatedly applied it in enterprise projects. data transmission can be secured through https.
   • con:
     requires a web server to implement

2. send a mail using an attachment (for some details see here):

   • save the body of your message to some file on the desktop.
   • generate a mailto-link that references an attachment (instead of the bulk of your body)
   • any decent mail client will be able to show the attachment inline if it has some elementary mime type like ‘text/plain’.
     on windows platforms you set it by choosing the proper file extension (‘.txt’)
   • pro:
     simple
   • con:
     file system access on the client platform;
     untested (at least by me)

good luck !