I'm currently maintaining a Desktop Java application that has a small to medium user base. I often get some pretty useless mails saying that "something went wrong" and I'm left digging through the source code, often unable to reproduce the problem.
Now I'm wondering if there is a library that would allow me to collect Exceptions when they happen, present a small dialog to the users and if/when they agree, post the stack trace to my webserver. Basically what I'm looking for is something similar to Application Crash Report for Android (ACRA), but for desktop Java applications.
If you are using SLF4J and Logback, you can configure an appender to send detailed error reports to a Ctrlflow Automated Error Reporting server (which offers filtering and aggregation of incoming reports + dashboards + email digest). This blog post has all the information on how to configure Logback accordingly.
If you want to present your user with a confirmation dialog first, you may have to extend the existing appender, though – unless your “Desktop Java application” is an “Eclipse Rich Client Platform applications.” In that case the work has already been done for you. See this webinar for more information.
Related
I'm looking for some advice on best/common practices with writing a log for a game server I wrote in Java (first time with server/client concept and I've never done anything with logging). I've tried some Googling, but the keywords involved are kind of vague and not coming up with any answers to my questions.
I have a server with users, game lobbies, and games. I think that I should create a log to keep a history of everything that happens on the server. And in this log I think I should record status changes of both the server itself (startup, shutdown, commands being processed), and socket connections (new/lost clients, incoming/outgoing messages).
I'm not sure if that's the best thing to do, or instead/also have a log with more human readable messages like "Bob781 joined lobby #4." or "microman12 beat sun44 in a game."
Should I write logs to the console or to a file? (2 separate files?)
What formats are best or most commonly used? Should they be the same formats?
I've come across the "Common Log Format", is this the best format choice for socket connections? Can it be used for the server statuses?
Should I use something in java.util.logging or just output the strings myself?
You always want to look for existing solutions before starting from scratch. When you use/create the logging, I would suggest the following tips based on my experience
Make sure you can reliable retrieve the logs whenever you might need them.
Make it easy to find a log file based on what you're looking for. For example if there is a problem with a specific game lobby, you should be able to easily navigate to the file or directory of files that pertain to that game lobby in question. Nothing worse than having to parse a huge gigantic log file...
Make each logging message meaningful. Don't just log stuff for the sake of logging. You will want to be able to read a log message and know relatively where in the server code that message is coming from. This will help later down the road when you run into bugs in your server code.
Have each log message time stamped at the point it's created and not when it's written to the log file.
I have come to know about TravisCI. It's great for testing syntactical bugs and resolving them but if that's the only functionality it provides, then I think Travis isn't worth it for testing. My only question is, does TravisCI automatically tests the code for exceptions/errors which might occur when the user is using the app? Are their any pre-requisits for this?
I'm worried that I understand your question correctly.
TravisCI is a combination of builder and test runner, not a monkey-testing program. You need to write code for Andoid unit-test and autonomous UI test based on your service logic, and also need to use additional app feedback program if you want to get information(stacktrace) of some error occured from users.
To write a unit test, see the official Android tutorial at below link.
https://developer.android.com/training/testing.html
Also, you can command monkey testing.
http://developer.android.com/tools/help/monkey.html
And, in order to get error feedback, there are many projects and services to do this. Android Play Store developer console provides in ANR & Crashes menu. Or, Crashlytics provides errors in more arranged manner. Consider ACRA if you are in a security-sensitive company as it allows you to install to your own server. When user got crash, stacktraces will be automatically collected.
I'm currently working on an App, which writes millions of lines to logcat (debugging output). I catch all these Informations (at runtime) by filtering the logoutput (of logcat) and write all the information in a file (redirect locat to a file). Unfortunately this takes very long and therefore the app runs very slow.
Now I wanted to ask, if there is a way, how i could get all these information faster. Is it faster, instead of writing the debugging information to logcat, to directly write the information to a textfile (on the device), or does anyone know a better way to gather these lines more efficient??!.
Thanks for reading,
greetings B.
There exist multiple logging tools. I recommend having a look at Timber trees.
But please listen on Jake Wharton:
Every time you log in production, a puppy dies.
Here is a list of logger tools from awesome-android:
logger - Simple, pretty and powerful logger for android
timber - A logger with a small, extensible API which provides utility on top of Android's normal Log class.
LoggingInterceptor - An OkHttp interceptor which pretty logs request and response data.
Bugfender - Upload your logs and check them online, specially made for mobile
EzyLogger - Simple Lightweight logger
Logback Android - Logback port to Android which provides a highly configurable logging framework for Android apps.
Punt - cli tool that makes adb logcat better
Do you know any good crash reporting systems for Java or any open source projects which use a crash reporting system?
Starting from simple
In case you want to report errors and exceptions to user in Java Swing Application htere is a nice library zeus-jscl that has several useful components:
gr.zeus.ui.JMessage - Displays simple messages and the stacktrace of an exception and more
gr.zeus.ui.JConsolePane - A java console to replace the command line window. Redirects the stdout and stderr etc.
This is sent nowhere it just locally convenient.
All of this brings me to how handles unhanded exceptions that occur in the wild. NetBeans pops up this little dialog and asks you to send in your report. Once you do send it, it's almost magical, reports are queued, analyzed, associated to either a new report or an existing report and finally the generic reports are associated to an issue in IssueZilla and it does it all automatically. If the issue is fixed, it even tells you in which, upcoming or not, version it has been fixed.
from here
You can download sources of NetBeans and rip off what you need. Read here how
The crash dump is just a text file. You could write a script which repeatedly runs your problem and mail you/notifies you of any new crash dumps.
I've been learning Java for about a month now, and not very familiar with a client/server situation like this one.
Basically I ran into a situation where our client java software (GUI) displayed a nullpointerexception popup but no stack trace on the client side. Someone had to go check the server side for the stack trace.
My question is, shouldn't the client side receive this precious information as well? Are situations like that ok, the rationale being one only needs one copy of the stack trace?
Not really. It is not recommended to show the way your app works from behind to the client. Mainly for security reasons. Your stacktrace shows all the objects being called, methods and if compiled with debug info, even lines. That's too much information for the client, it is ok to have it on the server.
This among SQL injection, Cross side script and others that I cannot remember, improper exception handling is a security vulnerability.
EDIT:
Here are other vulnerabilities ( although I don't see this one listed :( )
http://en.wikipedia.org/wiki/Vulnerability_(computing)
The client only needs to know hat it needs to know.
In alot of cases it perfectly fine to not show any stacktraces on your client.
Your users should get clear error messages but dont care about a stacktrace.
For debugging purposes a stacktrace is generally lost anyway, application gives errors, users restart it and gone is any excpetion, so if you need to know the errors use a logging framework.