Develop Reference

Is it a good practice to log line number in error code to the user?

I have been tasked with logging the line number as part of the error code shown to the user. Currently I am using:
StackTraceElement[] stackTraceElement = e.getStackTrace();
lineNumber = stackTraceElement[0].getLineNumber();
I know that the above approach may fail depending on the JVM version.
Also, I have seen the PatternLayout where it is mentioned that "Generating caller location information is extremely slow. Its use should be avoided unless execution speed is not an issue.".
Since this message will be presented to the user, should I still log the line number as part of the error code? I am trying to understand the pros and cons of this approach. Also, does the log4j warning apply only to its own implementation or rather is it a warning against location information generally?

Well, generally speaking your program should report two kind of errors:
The errors that are for the user (when the user is not doing what is expected from him), which should actually be better called "feedback" to help him feed your program with the right data (that's good UX practice).
The errors that are generated because of a bug, which are actually not targeted at the user, but at you the developer, sadly through the user. Then yes, it might be a good idea to log line numbers (or give your errors unique names/identifiers so that you can trace easily where it's been sent from). But a better idea is to then use a framework to report such issues directly to you through Internet (good practice being to ask for permission first).

What you should show to the user is what went wrong and what he can do about it, if anything. The line number information needs to be available, e.g. via a 'More details' button, in case he needs to raise a support ticket, but you don't want to frighten him or confuse him with it up front. Just look at how many stack traces get misread or indeed ignored completely here, and this community is supposed to be computer programmers.

Generally its better if your program doesn't give errors, and can receive all input, and give you tips on how to use the application. This will give users a much better experience if you want them to buy your product, etc.. If your program does give errors, it will not be helpful for the user to know the line number. You however will want to know the line number, so you should make it display a message of some sort that tells the user to email you the stack trace when the error occurs. Or you could have it report the error message automatically and email it to you.
Sorry, I'm a bit late I was unclear what the question was asking, so I posted this as a comment, but clearly it is an acceptable answer.

How to send android app logs to remote server?

In my application, I want to send logs in case of crash to remote server. I have added try-catch block and in catch I'm sending logs to server. I want to know what all exceptions should I catch. I need logs in case of every crash so that I can fix it. Would it be a good practice to catch all Exceptions?
Thanks in advance.

Here is a summarized list of suggestions I curated from other great answers:
Catch all unhandled exceptions.
Create an ExceptionHandler that implements java.lang.Thread.UncaughtExceptionHandler. You can use this class to customize and log errors.
Put this: Thread.setDefaultUncaughtExceptionHandler(new UncaughtExceptionHandler(this)); inside OnCreate() method (after super()) of each of your Activity class .
For details, please refer to this great answer from Android exception handling best practice .
Enclose try/catch around all codes that run externally/from outside. (e.g - codes using 3rd party components)
Enclose try/catch around all codes that you know, can fail on certain conditions
When there is no internet connections
During I/O Operations
When there is potential for crazy user inputs
When there is potential for divide by zero situations
Use try/catch at the top level because all exceptions are bubbled up to the top level. So, in inner functions, if need be, you can consider using throw exception. Then, at the top level, catch specific exceptions and sort your exception types in catch block correctly. (Referred from this great answer: How using try catch for exception handling is best practice
For UI, you should offer "continued usability" by providing "limited functionality" version of the app even if the error occurs (if the error is due to, for example, no internet connectivity).
Over-eager error reporting to user is not a good idea.
Persistent error messages are bad. Inform user with a message and let the user close/remove it.
Reference 1 | Reference 2 | Reference 3 | Further Reading 1 | Further Reading 2 | Further Reading 3
For an Android library to remotely log unhandled exceptions, you can take a look at this: android-remote-stacktrace .
Download .jar file.
Add it to Java Build path.
Add INTERNET permission: uses-permission android:name="android.permission.INTERNET"
In the OnCreate method of your activity or service, put 'ExceptionHandler.register(this, "http://your.domain/path");'
On your server, place this PHP file, which you can edit to extend the functionality.

You can use Crashlytics or Bugsense
https://mint.splunk.com/
https://try.crashlytics.com/

Should I throw an exception or print out an error statement in a program?

I have my program working and all done (java). It's a short and easy program for a job interview. I handle stuff like improper input format by throwing a custom exception. Is that the best way to do it or should I just make a print statement?

Exceptions are only useful if they will be handled by other code.
If you're writing a reusable library, you should by all means throw an exception.
There is nothing more frustrating than calling a third-party library that logs errors to the console instead of telling your code about them.
However, if you're writing a standalone utility, it's nicer to print friendly error messages than an ugly stack trace.
The most flexible approach is to write reusable code that throws exceptions, then add catch blocks in main() (or elsewhere in the standalone portion) that prints friendly messages.

If you handle improper format inline is the code readable? If so - fine, if not - throw an exception and handle it elsewhere
Are you able to handle improper format properly in the place you are parsing it or maybe some more generic method/class/module is actually calling your routine and should decide what to do? If the latter is the case -> throw an exception
In general - it depends. If you can handle this special situation "inline" - you can do it (make sure it's readable). If not - throw an exception.

Here's a good reference on exception best practices. You should make sure you are following these.
In your particular case (based on the details you have provided) a user may upload/select a file that has bad data. You program should handle that by catching any basic Java runtime issues and returning information to the user (not "Exception in thread..." but something more readable to a user). If you are checking for these alpha characters then you should just handle that (with an error to the user) without throwing an exception - unless this is truly the behavior you want.

Exception are cause when the program cannot work in a normally correct manner.
The exceptions get more complicated and increase in numbers when you evolve from j2se to j2ee.
For a stand alone application
If your application is just a extremely simple calculator then you may just completely forget about exception because your user input would be filtered and one of the few exception would be division by zero
If your application is a simple utility tool say screen capture , then if your file cannot be saved (exception at file i/o) then all you need to do is simply terminate all your task and say some error message to the user.
For an advanced project of example 2 , you need to save the image in a temp , and perform saving of file once the issue is rectified
For a enterprise scaled and distributed application
Here transaction(inter related activities) is involved . Here a simple message to the user is also needed at times and also handle(do needed changes to related transactions) the exception !
If the application is distributed in many countries then exception in one traction needs alteration in another server in another country , this demands optional incorporation of a some thing that uses JMS API(message sending inside application)
JPA (java persistence api) implicitly rolls back the database on event of a exception and provides facility to do so for interrelated transactions . But still the roll back only affects the database and not the instance variable(object values)
and at all times you don't want to user to read your exact stack trace that says error at line number .....

How to handle java exception in user friendly way

I'm developing a swing application and I'm a bit confused how can I handle exceptions for example lately a part of my code rename files, So when I was testing it I came up with a "you don't have permission to rename file" as I got it from print exception message. So How Could I express this message to user? and should I use JOptionPane message or just show it on the status bar?
Thanks

From your question it sounds like you already know how to handle the exception in the java sense. However you are looking for advice on how to react to exceptions once you have caught them.
In the specific example you give in your question I (as a user) would want that error presented quite clearly so a JOptionPane may be your best bet. I wouldn't just update the status bar as that is very close to silently failing and the user will just be left confused.
A personal rule of thumb is that if the user is likly to be waiting on the code to complete before getting on with their task then they must be informed of the failure strongly i.e. a modal box. If the failure is in a background task that the user can carry on without caring about, or the code can recover from it, or the code is going to retry, then I would go with the more subtle approach of the status bar or icon change depending on the UI.

To elaborate on a comment made by Kevin D - it really depends on your expected user audience. If they are technically proficient you can use the exception text as is. If not then I would prefix the message with "An error has occurred, please contact your technical support personnel with the following information: " then append the error message and ideally a unique identifier for locating an associated log entry... I often use a timestamp for this.
If you really want to get fancy you can email the tech support people with much more detail like the exception and full stack trace, copy of log entry, etc. I have done this in the past but you have to be careful as a frequently occurring error will quickly flood an inbox :)
Of course if the error can be fixed by the user then you can just say so (and how to do so) in your message. That is about as thorough and fancy as you can get...

I don't quite understand the first part of your question, but I try to answer the second one. In general, how you want to display an error to the user depends of the software and error. In most cases JOptionPane or similar is appropriate. However, in some cases a modal dialog might be too intrusive and status bar might be a better way to go. But again, this depends on what kind of software you're writing.

If you anticipate an exception could occur as a result of a user action, then you should explicitly catch it at the point that makes sense and ensure your program recovers correctly.
For example if the user can rename a file, you might invoke a rename() method which returns a status code to indicate success or a failure error code. Inside the method one of these codes might actually be triggered by an exception but the calling code doesn't care. Once the call returns, the status code can be used to determine which error message to show (if any).
enum RenameStatus {
Success,
Failed,
SecurityFailed
}
void doRename(File fromFile, File toFile) {
switch (rename(fromFile, toFile)) {
case Success:
break;
case Failed:
// todo generic dialog rename operation failed
break;
case SecurityFailed:
// todo security dialog rename operation failed due to permission
break;
}
}
RenameStatus rename(File fromFile, File toFile) {
try {
if (!fromFile.renameTo(toFile)) {
return RenameStatus.Failed;
}
return RenameStatus.Success;
}
catch (SecurityException e) {
// Error - permission error
return RenameStatus.SecurityFailed;
}
catch (Exception e) {
return RenameStatus.Failed;
}
}

If you catch the expression (enclosed in a try - catch - block) you get notified when this exception occurs. Then you have to decide: Is there a way to make things work again? Could you, for example, ask the user for another file name? Then do that! But if there is no sensible way of circumventing the error, then just have the program abort.

File permission is kind of a "normal" exception, not a truly "exceptional" one as "disk full" would be, so you'd probably just use JOptionPane instead of sending an error report. That being said, some earlier answers are very informative and should be adopted for the general cases.
In addition, my main() always start with this:
Thread.setDefaultUncaughtExceptionHandler(new UncaughtExceptionHandler()
{
public void uncaughtException(Thread t, Throwable e)
{
// do your things: see earlier answers
}
}

Use Try-Catch handling...
http://tutorials.jenkov.com/java-exception-handling/basic-try-catch-finally.html
When you catch the exception you can do whatever you want with it. Display it to the user, do something else in the code, display another message to the user based on the exception, etc.

Where to handle an Exception

I'm currently working on a project and I've come upon a bit of a head scratcher. I've been programming in Java for about two years, and I've covered exceptions, but never properly understood them.
In my current situation I've got my main method which initializes a class
WikiGraph wiki = wiki = new WikiGraph(getFile());
The Wikigraph constructor takes a filename which I get via a DialogBox in the getFile() method.
The constructor for wikigraph then calls a method called loadfile(filename) which attemps to load and parse the file given.
The loadfile() method is where I will throw an IncorrectFileTypeError.
My question is, where should I handle this?
At the moment I catch it in the loadfile() method
try {
//load file
} catch (IncorrectFileTypeError e){
System.out.println("Incorrect file type: "+filename+": "+e.getMessage());
throw new IncorrectFileTypeError();
}
But I also catch it at the WikiGraph initialization like so:
while(wiki==null){ //While There is no valid file to add to the wikigraph
try {
wiki = new WikiGraph(getFile()); //Try to load file
} catch (IncorrectFileTypeError e) { //If file cannot be loaded
JOptionPane.showMessageDialog(null, "Incorrect File Type Given. Please Choose another file."); //Display error message
getFile(); //Prompt user for another file
}
}
Now is the way I've handled the error the correct/best way? Or should it be handled elsewhere, such as in the getFile() method?
EDIT: I suppose I should make the file issue a bit clearer.
The File extension is not what the IncorrestFileTypeError is based on, and thus it may be a misleading error name.
The file given may have pretty much any extension, its the contents of that must be well formed.

In this case, I would avoid using exceptions as your primary method of dealing with incorrect file types. If an exception can regularly be triggered by user input, it really shouldn't be treated as an exception. Here's the approach I would take:
Check the file type and alert the user if the file type is invalid, through standard control flow. You might consider a static method on WikiGraph like IsFileValid(filename)
In the WikiGraph initialization, throw an exception if the file type is invalid.
This approach gives you the best of both worlds - you have the opportunity to alert users when invalid data is provided, while still ensuring from WikiGraphs perspective that the information provided is accurate. It gives developers working against a WikiGraph a way to ensure their input is valid without necessarily requiring exception handling.

One of the main benefits of exceptions is that they give you convenient means to handle an exception far from where it occurs. In languages that don't support it, you would have had to have each call on the path check the return value, break and return, so that you are manually propagating.
It makes sense to handle the exception where you feel you can either recover from it or best report it and cancel the operation.
My understanding is that the interaction starts with UI input and that if the file type is inappropriate, you cannot really recover. Therefore, I would have whatever UI task that initiated the file open catch the exception, report to the user that an error occurred, and either cancel or ask for a different input.
On a second reading, it seems like you are opening the dialog after you've already started trying to create the graph. I personally like to isolate UI interaction. I would therefore personally first handle all UI input, get the expected file name, verifies that it meets my needs, report to the user if not, and only continue further if the file is ok, then reporting only critical and unexpected errors.

I don't think it makes sense to catch it in loadfile. You can still write a log message (use System.err), just do it before throwing the exception. You're on the right track with catching the exception where you can do something about it (in this case prompting the user again).

If the problem is that the user has choosen a file of the wrong type then I don't think you should let the code proceed that far at all. This does not really seem like it should be an Exception at all but more a path in the program. If the user has selected an incorrect file type then he should be presented with the choice of choosing the file again. Obviously you should limit the choices in the JFileChooser to files of the correct type if it is as easy as looking at the extension.

I think this is the type of situation that checked exceptions are designed for (whether you agree with them or not.) I assume IncorrectFileTypeError extends Error? Extending RuntimeException would be more appropriate, and extending IOException would be better still, because this kind of error can be triggered by valid user input (i.e. typing the name of a file that exists but has the wrong type.)

I believe this type of error (IncorrectFileTypeError) can be resolved in the User Input Form avoiding an unnecessary roundtrip to filesystem service layer.