I am new in Android environment and I have started writing some code to execute some queries on a database. When I have to handle exceptions I don't know what the appropriate way is to do it - out of Android I used to use throws declaration on methods but it seems that throws isn't allowed in android? Just try-catch?
I say this because eclipse doesn't suggest me adding throws declaration like when I am out of Android environment, I guess that it is related to extends Activity.
So what is the appropriate way to handle exceptions in android? Surrounding every sentence with try-catch makes my code look terrible and that's not really what I want to do.
If the method you are using already throws an exception, you may want to just re-throw the exception as the new type:
public void someMethod() throws IOException {
try {
// Do database operation
} catch (MyException e){
throw new IOException(e.toString());
}
}
// Or, if there is no exception, use an unchecked exception:
public void otherMethod() {
try {
// DB operation
} catch (MyException e){
throw new RuntimeException(e);
}
}
The other option is to make MyException extend RuntimeException. Then the compiler won't force you to catch it or add it to the method signature. RuntimeExceptions are known as unchecked exceptions meaning you don't have to check for them occurring by way of a try/catch. Examples of these are NullPointer and ArrayOutOfBounds.
I just was wondering about some strange handling of "throws" in Android environment and found this old question here.
Asker Jon "started writing some code to execute some querys on a database", so maybe he noticed the same as I did.
This compiles without error:
public void onCreate(SQLiteDatabase db)
{
db.execSQL(DbMeta.T_DISGUISED.T_CREATE);
}
Despite this declaration (in javadoc popup):
void android.database.sqlite.SQLiteDatabase.execSQL(String sql) throws SQLException
So first, monkjack is right when he points out that onCreate method's signature cannot be changed by inheriting implementations.
And second, Zeki is correctly indicating the difference between checked and unchecked exceptions.
And now third, I want to add that the big confusion is caused by SQLException.
The SQLException used in the example above is Android type android.database.SQLException and inherits java.lang.RuntimeException - it is an unchecked exception! No throws declaration required!!!
That is not the classic java.sql.SQLException - which is a java.lang.Exception and requires try/catch/throws.
The reason you can't "add the throws in android via eclipse" is because you are not the person who defines the interfaces or super classes. If you want to add an exception to the method signature (like you say you do normally) it also needs to be added to the interface and you are not in control of them so you can't change it.
Eg the method
protected void onCreate(Bundle savedInstanceState);
which you override in activity, if you want to throw an exception the method signature would need to be changed to (for example)
protected void onCreate(Bundle savedInstanceState) throws MyException;
but then it would also need to change where onCreate is defined, which is in the Activity class - and that is a class you can't change (because its provided by the android library).
Therefore your only option is to catch the Exception and do something with it (or just ignore it). You could make a toast to display the errror
catch (Exception e) {
Toast toast = Toast.makeText(this, e.getMessage(), Toast.LENGTH_SHORT);
toast.show();
}
Related
This is a plain Java 8+ question, no frameworks used.
We are producing an API for a higher layer which deals with the presentation layer among other activities. We have and interface agreed with the invoker, so they are happy to receive some particular exceptions we throw.
At the same time, we are also using other APIs under the same agreement, so we can do stuff by ourselves and throw exceptions or we can invoke other APIs which throw the agreed exceptions.
Currently, we do nothing with the exceptions thrown by the APIs we are invoking.
Thing is, we are the best positioned in this infrastructure to deal with intermediate activities while exceptions are thrown, so we need to capture both, our exceptions and the exceptions provided by those we are invoking; basically reporting the issue, raising system controls, etc, and then re-throw the original exception so the top layer keeps as it is now.
We have around 300 methods in the entry point class of our API:
public void method1 (arguments for method 1) {
...
}
...
public void method300 (arguments for method 300) {
...
}
I clearly understand that I can create a method to centralise the actions to be taken in the exception management, something like:
public void myExceptionHandler (Exception e) {
if (e instanceOf X) {
} else if ...
...
throw particularExceptionAccordingTheCase
}
But I'd also avoid modifying those 300 methods.
Any idea how to inject a try-catch in those 300 methods to send the Exception to myExceptionHandler without really adding a try-catch in each of them?
Any comments and ideas are much appreciated!
----------- After mprev0 suggestion -------------------------------
I tried this approach. It really catches the exception and so on, but I can't re-trow an Exception: I'm forced to catch it, but this goes against the requirement of re-sending the exception back to the top layer.
While I can throw an Error, I got a compiler error at line throw new FileNotFoundException();
public class myExceptionHandler implements Thread.UncaughtExceptionHandler {
#Override
public void uncaughtException(Thread t, Throwable e) {
System.out.println("gotcha!");
if (e instanceof java.lang.Error) {
System.out.println("AAT-CORE: Fatal Error");
throw new java.lang.Error(e.getCause());
} else if (e instanceof java.lang.Exception) {
System.out.println("AAT-CORE: Exception Error");
throw new FileNotFoundException();
}
}
}
Any ideas?
------------ After some more digging, fixed with a decorator pattern -------
Previous class implementation does not work, as I can't change the signature of the method and I need to re-throw the java.lang.Exception.
Using a decorator and handling the interface there makes the trick.
As a summary:
Top layer class:
public class TopLayer {
public static void main (String[] args) {
MiddleLayer m = new MiddleLayer();
m.method1();
}
}
Bottom layer class contains specific APIs and some implementation, the only interesting thing is that it contains java.lang.Exceptions uncontrolled, expecting the top layer to do this job. But, we are working in the middle and we will do this job:
public class MiddleLayer extends BottomLayer {
public MiddleLayer () {
final UncaughtExceptionHandler subclass = Thread.currentThread().getUncaughtExceptionHandler();
Thread.currentThread().setUncaughtExceptionHandler(new UncaughtExceptionHandler() {
#Override
public void uncaughtException(Thread thread, Throwable ex) {
System.out.println("gotcha2!");
// carry on with prior flow
subclass.uncaughtException(thread, ex);
}
});
}
}
In this way, I can get the system.out and the java.lang.Exception is propagated to the Top Layer.
Decorator inspiration came from here: Rethrow UncaughtExceptionHandler Exception after Logging It
Additional comments are welcome!
You can solve this by implementing the java.lang.Thread.UncaughtExceptionHandler interface:
public class MyExceptionHandler implements Thread.UncaughtExceptionHandler {
#Overrides
public void uncaughtException(Thread t, Throwable e) {
if (e instanceOf X) {
} else if ...
...
throw particularExceptionAccordingTheCase
}
}
Then you associate it to all threads as follows:
Thread.setDefaultUncaughtExceptionHandler(new MyExceptionHandler())
This will configure the exception handler to handle all uncaught exceptions in all threads of your application.
Note that this will only work for exceptions that aren't yet explicitly handled somewhere in your code and if there is no other handler configured for some particular thread (the uncaught exception handler can also be set for some specific thread).
EDIT: As discovered by #JBC, the above approach will not work for checked exceptions since we are forced to catch them explicitly in our uncaughtException method (note that we cannot add a throws clause to an overridden method). While it will work without problems if we only want to re-throw subtypes of RuntimeException and Error, there is a little adaptation needed if we want to make it work - you can find it explained in #JBC's question.
As you can see in the question updates, the final solution is a combination of two different approaches, in one side, having the mprev0 approach of implementing the java.lang.Thread.UncaughtExceptionHandler and, on top of this, adding a Decoration pattern to be able to re-throw a run-time exception.
There were no additional approaches so far, so I'm closing the question and bring this as the most complete response.
More information about UncaughtExceptionHandler can be found in the Java documentation, but as always, is short on examples, and here:
Advanced exception handling
Thread.UncaughtExceptionHandler Example
More information on Decorator pattern usage, can be found here:
Decorator Design Pattern in Java
Design Patterns - Decorator Pattern
And how to use to manipulate exceptions here:
Rethrow UncaughtExceptionHandler Exception after Logging It
You could also create a proxy API on top of your current API, have an invocation handler method in the proxy and put this method in a try catch block.
https://docs.oracle.com/javase/8/docs/technotes/guides/reflection/proxy.html
https://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Proxy.html
The following text is from "Effective Java", Item 2:
The traditional Abstract Factory implementation in Java has been the
Class object, with the newInstance method playing the part of the
build method. This usage is fraught with problems. The newInstance
method always attempts to invoke the class’s parameterless
constructor, which may not even exist. You don’t get a compile-time
error if the class has no accessible parameterless constructor.
Instead, the client code must cope with InstantiationException or
IllegalAccessException at runtime, which is ugly and inconvenient.
Also, the newInstance method propagates any exceptions thrown by the
parameterless constructor, even though newInstance lacks the
corresponding throws clauses. In other words, Class.newInstance breaks
compile-time exception checking. The Builder interface, shown above,
corrects these deficiencies.
Please go to this link for full text.
I've been able to follow everything before, "In other words..". Can someone please explain how does newInstance break compile-time exception checking and how does Builder pattern fixes it.
'newInstance' doesn't know ahead of time (at compile time) what exceptions could be thrown, as a normal class method would (because of the way code dependencies are built, and because a class has to make known which exceptions it throws).
The Builder pattern uses a class that takes a request (usually via a method) and creates a new object instance based on steps (most likely defined in that class).
Conceptually a non-abstract factory, and builder are very similar.
public class Main {
private int i;
public Main() throws IOException {
throw new IOException();
}
public static void main(String[] args) {
Class c = Main.class;
try {
c.newInstance();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
}
}
}
In my opinion, if we use class.newInstance() method, we will never know the exactly exception will be thrown by the construction even though the exception is a checked exception and the checked exception isn't shown at the method signature. Just like the example above. If we use class.newInstance(), we will forget to handle the IOException and then get a "broken object". But the Builder pattern won't. Sorry for my pool english and hope you can understand.
I am using SonarQube and it shows the following error:
Public methods should throw at most one checked exception.
// Noncompliant
public void delete() throws IOException, SQLException { /* ... */ }
// Compliant
public void delete() throws SomeApplicationLevelException { /* ... */ }
Does this means, SomeApplicationLevelException is a parent class and IOException and SQALException are derived from it? And we should throw the parent class exception? Thereby adhering to method throwing only 1 checked exception?
Because I have 2 exceptions that i have defined say for example Exception1 and Exception2 that extend Exception. And my method say, sampleMethod() throws them i.e,
public void sampleMethod() throws Exception1, Exception2 {
}
And the error is shown here. So should I have one class as parent (say MainException) and derive Exception1 and Exception2 from it and throw parent exception class? Like below:
public void sampleMethod() throws MainException {
}
Is the above solution proper?
If you have a method in your application that is declared as throws SQLException, IOException, you are probably leaking internal implementation details to your method's users. Specifically, you're saying:
Your method is implemented using JDBC and file I/O. Your users don't care how your method is implemented; they only care about what your method does.
Your method, including any future version of it, will never throw any other checked exception. If in future you change your method so that it might throw another checked exception, it will break backwards compatibility.
The advice is to create your own application-specific class (derived from Exception), and only throw that in your method. You can, if you like, wrap the SQLException or the IOException (or any other exception) inside your application-specific exception as the cause.
Note, however, that there is a school of thought that says Java checked exceptions are a bad idea (and one of the reasons C#, and more modern languages such as Kotlin, don't have checked exceptions).
UPDATE: the above answer related to the first version of the question (edit #1). The question was subsequently updated to point out that the two thrown exceptions were application-defined ones, so therefore much of the above rationale no longer applies. The answer to the updated question is explained in this post.
IOexception and sqlexception both are checked exception s,totally different from each other , now if we extend both from one exception and throw the parent exception , which is not a mandatory in java, it will be kind of misguiding the user of the api.
However, if you want to do it in ur app to avoid sonarqube error , you can catch all your specific exceptions and throw a custom exception wrapping the original exception information in exception message.
for example
try{
///piece of code that throws IOException and SQLException
}catch(IOException | SQLException ex){
throw new DataException(ex,"Any customized message you want");
}
This DataException will then will be included in the throws clause of method signature having this try catch.
DataException extends Exception class and by passing ex in the contructor you are wrapping the original exception in custom exception with your original exception info preserved.
I'm trying to integrate Facebook into my app so I followed all the instructions. When running it, after onResume event finishes, I get an exception that I can't catch from my code.
Is there a way to set a general exception catcher so no matter what, it will catch it?
The emulator does not throw any exception at all so I can't use it for this
Update: I found it here: Using Global Exception Handling on android
The error came from Facebook itself and it is related to working with proguard
try this solution:
create a class that implement Thread.UncaughtExceptionHandler (this
class going to handle with the uncaughtExceptions), lets call this
class ExceptionHandler.
create a class that extends Application,
lets call this class App, and don't forget to declare this in the
manifest file under application tag: android:name="your_package_path.App"
in your App class override the method onCreate(), and add this line: Thread.setDefaultUncaughtExceptionHandler(new ExceptionHandler(this));
The Throwable class is the superclass of all errors and exceptions in the Java language.
If you catch a throwable you can catch all kind of errors and exceptions.
try {
// code
} catch(Throwable e) {
// handle throwable
}
However this is strongly not recommended and bad practise/design. You should never catch generic errors and exceptions. You should analyse your specific exception and solve the problem instead of simply ignoring it with try/catch!
There is a base Exception class. So if you do like this:
try {
...anything...
}catch(Exception e) {
e.printStackTrace();
}
you'll catch any exception that is thrown by any method called from within the try block.
But remember that exceptions aren't always thrown. Sometimes there's just no result to return, or something.
Is there a possibility in Java to get rid of the necessity to catch non-RuntimeException exceptions? Maybe compiler flags?
I know the reason why the catching is promoted, but want to do simple and straight tools that enforce their requirements. So if something can went wrong I don't like to catch up but exit the application, crashing with a meaningful exception. Usually this ends up like:
try {
connection.close();
} catch (IOException e) {
throw new RuntimeException(e);
}
which introduces 4 lines of code mess, and introduces the wrapping RuntimeException mess on error output. Sometimes it even motivate people to wrap large try ... catch (Throwable ..) blocks around anything, which is the likely cause for our beloved 'Unknown error occured' alert boxes...
you can use throws keyword with method prototype to avoid try-catch block. which eventually throws the exception to JVM's Default Exception handler which halts the application if no catch block's are specified in your code to handle the exception raised.
Crashing the application at the first sight of an exception is very bad practice. Especially when some work is unsaved and the application is using some resources that needs to be freed and cleaned before the application terminates execution. Some very popular software used to do that... and instead of "fixing" the issue, they introduced a data recoverability features on application restart. However the trick, this is not good software engineering.
At the very least, your application should not crash on the first exception/error encountered, but recover with a meaningful message. It is being lazy to just wrap everything in a RuntimeException (or even Throwable) and, especially, not do anything with it.
Java does not support flags of any kind because there are 1) a workaround, and 2) better ways to handle this situation. For example :
1. Handle the exception in the calling method
You can add the throws keyword in your method declaration, up to your static public void main method, which, if not handling the exception, will eventually crash the application with a stacktrace.
class Foo {
public void someMethod(....) throws IllegalArgumentException, IOException {
...
}
static public void main(String...args) throws Throwable {
new Foo().someMethod();
}
}
This method does not offer any means of recoverability and will probably make your user unhappy (with a big meaningless stachtrace if they ran the application from a console, or just nothing at all if they launched it from a shortcut or GUI). Also, if you have some acquired resources, you will not be able to clean them when an exception occurs. At the very least, your main should catch (Throwable e) and output something before throwing the exception above. Something like :
class Foo {
public void someMethod(....) throws IllegalArgumentException, IOException {
...
}
static public void main(String...args) {
try {
new Foo().someMethod();
} catch (...) {
// output or log exception here and, optionally, cleanup and exit
}
}
}
** EDIT **
Consider this scenario : a program is initializing some resource for processing some data, then some runtime exception (or error) occurs during processing, the application crash, but the resources are not released or freed. In Java, however, one could do this
public E doSomething() throws RuntimeException {
// declare a bunch of resources
try {
// process resources with unchecked exceptions
} finally {
// free resources
}
// return some result
}
and cleanly exit the method on error or on success, perhaps even logging the runtime error for "posterity".
2. Log the error and return some meaningful value
Logging is a very good practice. You can show your user some message telling them that the operation could not be executed without crashing the whole thing, and giving you some traces of what and where the user were doing. A simplistic logging system could be :
class Foo {
static private final Logger LOG = Logger.getLogger(Foo.class.getName());
public boolean doSomethingImpl(...) {
boolean result = true;
try {
...
} catch (SomeException e) {
LOG.log(Level.SEVERE, "meaningful message why method could not do something!", e);
result = false;
}
return result;
}
public void doSomething() {
if (!doSomethingImpl(...)) {
// handle failure here
}
}
}
By default, the Logger will output everything to the err output stream, but you can add your own handlers :
// loggers are singletons, so you can retrieve any logger at anytime from
// anywhere, as long as you know the logger's name
Logger logger = Logger.getLogger(Foo.class.getName());
logger.setUseParentHandlers(false); // disable output to err
logger.addHandler(new MyHandler()); // MyHandler extends java.util.logging.Handler
Java already ships with some default logging handlers, one of which writes to file.
etc.
Is there a possibility in Java to get rid of the necessity to catch non-RuntimeException exceptions?
For a checked exception, you can chose between catching the exception and declaring it in the method header as thrown.
Maybe compiler flags?
No. There are no compiler flags to relax this. It is a fundamental part of the language design. Relaxing the checked exception rules via a compiler switch would cause serious library interoperability problems.
I don't think that there's any way around this for the JVM. Your best bet is to have your methods re-throw the exception, which gets rid of the "mess" in your code, and then have your main program throw Exception. This should propagate the error up to the top of your program.
Keep in mind, however, that the place where the exception actually happens is a much better place to let the user know what happened (i.e., exactly what it was doing when this particular IOException happened). You'll lose this resolution if all errors are simply propagated up to the top level.
You do have the ability to throw your exceptions up a level. Here's an example
public class Foo {
public Foo() {
super();
}
public void disconnect(connection) throws IOException {
connection.close();
}
}
Use "Throws" to avoid the error..but it will not be good programimg practice