I was going through following tutorial: http://www.dreamincode.net/forums/topic/190013-creating-simple-file-chooser/#viewSource
Inside the FileChooser class there is one exception beeing supressed, since there is nothing within the catch clause. So I decided to add following statement to the catch clause:
Log.e(ACTIVITY_SERVICE, e.getCause().toString());
For some reason this always causes the app to crash (NullPointerException). When I don't do any logging, except for a a simple syso print, then I don't get any exception and the app does't crash either. Then it works fine. I'm new to the whole Android Framework and just want to understand why this is happening.
Thanks to Ingo's and CommonsWare's hints I came to the conclusion, that following line caused the exception:
EDIT:
In fact it was the start of the foreach loop, which iterates over all subdirectories and files of a given directory. I didn't know, that this would cause a NPE, if the list you want to iterate on is actually null. For some reason I thought that the loop would be automatically skipped in this case.
Related
So, I have this android application and even some users. As I have a crash report system, I can see when someone's app crashes and the cause.
It appears that, though rarely, the app crashes randomly with NullPointerException when it tries to change some attributes(rotation, text, etc..). I make sure everything is set first thing in the onViewCreated method(using Fragments) like this:
private TextView orientationView;
orientationView = this.getActivity().findViewById(R.id.orientationView);
Using this ^^ example, I then try to hide/show this view and get an exception as it appears to be null sometimes, which is what I struggle to figure out why.
orientationView.setVisibility(View.VISIBLE); // app crashes when orientationView is null
Being a newbie in android development, I am not sure if it is a good practice, but in some of the fragments, I set all the previously initialized resources to null in the onDestroyView method, but the one that crashes the most doesn't have this method implemented, which make me to believe that somehow the resources are just not found/initialized in some rare occasions and I fail to change them later with an exception.
Could someone help me figure this out :) (more description could be provided, if needed)
I am developing an Android app (It doesn't matter though) using RxJava2, and in some singleton there are some PublishProcessors.
And there are a lot of .onNext() calls on these PublishProcessors all over the project.
Now in order to debug, I need to know, on every .onNext() called, which line in my project invoked this .onNext().
Is there a way in RxJava(2) that I can achieve this?
I think you can use Frames tab in Debug menu.
For example, in this case, MainActivity line 18 trigger onNext
Ah, thanks to #PhanVanLinh, I found a solution that worked for me.
(Actually it has pretty much nothing to do with RxJava...)
You just need to print the stacktrace using Thread.currentThread.stackTrace and print it to your own string inside doOnNext(), but remember to do it before .observeOn() so that the thread won't switch, it must stay at the original thread that called .onNext(), otherwise you won't get meaningful information.
Then you will know which line that called .onNext().
I am new to android development. In the overriden onCreate() method of my activity, I perform some operations. For ex. check if SharedPreference is already available and then route to other activity. How do I perform exception handling on this onCreate() method. Is it the right way to wrap the contents in a try catch and display the error dialog on exception?
If the exceptions are not handled properly, in my case the onCreate() method, the app crashes with message:
Unfortunately your application stopped working
On searching in the internet, I found that UncaughtExceptionHandler could be used to handle it. Any sample implementation and how to call it from all my activities would be helpful.
THat's the wrong way to go about it. Instead, go into your logcat. Read the stack trace of the exception. Figure out what you did wrong. Fix it. Just catching exceptions is a horrible practice unless you're catching a specific exception for a specific reason- its very unlikely your app is in a state where it can continue correctly. Don't be lazy, track down your bug and fix it.
With something like this you can catch a generic Exception in your onCreate() method:
#Override
protected void onCreate(Bundle arg0) {
super.onCreate(arg0);
try {
// do whatever you need
} catch (Exception e) {
e.printStackTrace();
}
}
Exception catching can be used with many goals. An interesting one is to catch particular expected exceptions to fix some problems (for example setting a generic value into a variable otherwise null after occurring an error).
The general purpose however is to avoid that an error causes a problem or in the worst case a crash of your application. Depending oh what kind of software you are developing, a crash may represents a little problem (like in an Android app), a very big one (like in airplane's softwares or power plants' softwares).
We can identify two kind of exceptions.
The first type are those exceptions specific to definite problems. They have to be declared into methods signature, so you are encouraged or obbligated to manage these exceptions and their relative problems. These exceptions represent an error that should probably occur during particular code execution, like a parsing error, or an input output error. For this type of problems we have particular exceptions, to catch and easily manage them (for example as previously said to init a variable with a default value after an error).
The second type of those exception represents instead some generic problems that can occur during program execution. They are a big and generic set and generally their probability of occurring is low. For this reason you are not obbligated to manage them. The main example of this type is the general Exception class.
So an catching an Exception is not the right approach to solve a bug, as suggested by Gabe Sechan.
Catching a generic Exception in the main() Java method can be a way, for example, to show a default human readable error to the user if nothing else is available.
Or could be a way to keep the failing of the current operation reducing crash probability.
Now, in Android we can't act directly on the main() method. onCreate() method is executed and exited so catching here a generic Exception has no much sense. Obviously it depends also on what you do in your onCreate() method and what you want to do if an error occurs. You could do some strange stuff (is very defined what you should do in the onCreate() method) and you could need to manage a big set of problems only showing an error, so it has more sense catch only a generic Exception than a lot of particular exceptions to make the same thing in each catch block.
If you want to achieve this goal (a message showed for all the errors occurred during onCreate() execution, made Activity by Activity) this is the right approach.
If instead what you want to achieve is to intercept all of the errors that are generated during all of your app execution, a good approach could be the UncaughtExceptionHandler, that act similarly to catch a generic Excepetion into a Java main() method. At this level an interesting approach is described here.
For more infos about exceptions you can read this and this.
Did anyone has experience with MVEL2 on android?
i've tried out the same code with a simple java program and later on android:
The following exception is thrown when executed on android:
E/AndroidRuntime(30793): java.lang.ExceptionInInitializerError
I tried the example from the mvel website:
String template = "Hello, my name is #{name.toUpperCase()}";
Map vars = new HashMap();
vars.put("name", "Michael");
System.out.println(TemplateRuntime.eval(template, vars));
If theres no solution could anyone suggest a template engine which works with android
and supports iteration?
MVEL2 tries to substring the first 3 characters of the system java.version property when initializing the parser, and under Android the version is 0. That causes a bunch of exceptions which eventually cause the ExceptionInInitializerError.
If you want to force the java.version property, you can simply set it yourself:
System.setProperty("java.version", "1.6");
I have no idea what kind of odd side effects this may cause for Android, but at least it gets the MVEL parser up and running without throwing exceptions!
System.setProperty with "java.version" key seems to be read only propery in android, so it won't work.
i've tried to integrate MVEL 2 into android with no success, try using EVAL lib
I'm having a hard time figuring out what my problem is here. I'm receiving this error in my program, but it does not cause a crash or anything like that. I have an update I'd like to release, but I don't want to release it with this error being thrown at certain times. I've read all related posts on this error, but none apply to my situation.
I've made sure that I am closing my DatabaseHelper and SQLiteDatabase objects. I've also made sure that I'm closing all of my cursors. This error is pointing toward my method getActiveScheduleInfo, which returns a Cursor object. I've made sure that whenever I call this method, the returned cursor is closed in a Finally block.
Is this incorrect to do it this way? In my methods that call getActiveScheduleInfo, I have multiple return statements in them, based on certain conditions. So, instead of closing the cursor before each return line, I surround the condition testing with a Try, and close everything down in my Finally.
Everything looks like it should be working, so I'd really appreciate any help!
Thanks a lot!
Paul
I was able to figure this out! I hope that this helps someone else out there having the same problem.
I wasn't doing anything inherently incorrect here, but was rather taking too long to close some of my cursors. To give you a very brief background, I could not use a Managed Query or use startManagingCursor, since this code was in a custom class, not an activity. I am building against Android 2.0 (API level 5) so I am not using the new CursorLoader object.
I was taking the following steps:
Opening the database.
Creating a new Cursor and performing my query.
Iterating through the cursor and performing the needed tasks
Performing some other logic
Closing the Cursor and Database in a Finally block.
I found out that my step 4, performing some other logic, coming before closing my Cursor, was causing it to, for lack of a better term, timeout and cause this error. From now on, I read the necessary data from the Cursor, and not ONE LINE OF CODE FURTHER, I close the Cursor. :) This has completely eliminated these random errors, and I have clean-running code again.
I hope that helps others having the same problem! Take care,
Paul