Android's Log.wtf Method

And more importantly, if a function has [WifiResult] as the defined return type, you can be absolutely definitely sure that you get a list back.

This is not something inherently unique to Haskell. Any strictly typed language could easily have chosen to not let null be a member of all classes. Or at the very least add some "non-nullable" qualifier to types.

maybe I like this

That's actually a great idea. Can you recommend one such tool? I'd like to run it on the Android framework source and see what else I've been missing.

Well the documentation is very scarce, not just in the Looper class itself, but also in places where you mysteriously need one (i.e. LocationManager.requestLocationUpdates). I really don't get the point of the Looper class anyway, as (better) facilities to do stuff in separate threads already exist in the standard Java class libraries (i.e. Executor and ThreadPool come to mind which both work fine on Android). I also don't see why I should bring my own thread just to catch an event, you'd think the class library could do that for me? My main problem here is the lack of clear documentation explaining why I need this non-standard not-invented-here syndrome piece of crap. Compare this to the Executor class' documentation from the standard Java libs for example.

Then there's the way in which the constructor of the Handler class will automatically attach to the 'current' looper thread. If the current thread is not a looper, it will throw a RuntimeException. It would probably be appropriate here to create one's own Exception class rather than throw a generic one both for readability of the stacktrace and so you can catch it explicitly. To me is just another example of amateuristic/lazy software engineering and lack of understanding of general Java principles. Either way, this automatic association is not explained in the documentation of Looper, they just give the example and you're supposed to understand what's happening. I don't see what would be wrong with just creating a Handler and attaching it to the looper thread explicitly, if not just for readability's sake. My main gripe here is the lack of documentation, as if they really don't give a crap about whether or not you understand what you're doing, as long as you're copy/pasting their example you should be fine.

The naming is confusing. What the fuck is a 'Looper'? This name only makes sense if you're coming from C and I guess I'm old enough to get it, but come on people, there must be more descriptive names than that. Why am I posting messages to the Handler object? Isn't the looper thread supposed to post messages to the handler, which then 'handles' them? Do you post an event to an event handler? Why can't the functionality of Looper and Handler just be in one class? What's the use of the CallBack interface, if I can just extend Handler? In both cases I need to implement only a single method, so what's the point?

According to the docs this is the functionality of the Handler class:

    There are two main uses for a Handler: (1) to schedule messages and runnables to be executed as some point in the future; and (2) to enqueue an action to be performed on a different thread than your own.

Here's how Swing lets you do stuff in Swing's main UI thread:

    EventQueue.invokeLater( [your Runnable goes here] );

Here's how you run something in a separate thread using executors:

    executor.execute( [your Runnable goes here] );

This is how you schedule something that is supposed to run in the future:

    executor.schedule( [your Runnable goes here], 1000L, TimeUnit.MILLISECONDS );

"looking at the source" defeats the point.

he was talking about documentation.