Unexceptional Uses of Java Exceptions

What’s an exception?

Oracle, the current owners of Java, says:

Java (and many, if not most, other programming languages) provide an Exception as a way to handle errors. When a severe error occurs, the program creates an object and “throws” it. It travels up the call stack until another object that is capable of handling the problem “catches” it. If no one catches it, the error can cause the thread, and even the whole program, to exit.

Depending on how your code uses them adding a try/catch block to your code can be expensive, even if the exception is never thrown.  If your code throws, the impact can be worse.

They also look a lot like a GOTO. ’nuff said.

To me, exceptions are for exceptional events. We’re running out of memory. An external resource is gone. A reference became a null.

When an Exception is not Exceptional

Here is the signature for a commonly used method in QuickFixJ, an API I use:

It’s a method for retrieving the String value of a field in a FIX (Financial Information eXchange) message. If you ask for a value that is not there, it throws a FieldNotFound exception.

So, if you are working in an environment like mine, where whether or not a field exists is part of the message semantics and not an error, you end up doing this:

I work on software that routes a few million messages a day. It determines where to send them by checking which fields are set and what their values are. To avoid the expense of the exceptions, I have to check the value twice.

For people that work with a strictly enforced dictionary, a missing tag might be an exceptional condition. They’re like that TV lawyer that only asks questions she knows the answer to. Those of us that serve at the mercy of paying customers have to code around the developer’s opinions about FIX messages.

To be fair to QFJ, I did a pull request and asked that the exception be replaced with an Optional, and the compromise was to add a getOptionalString. This alleviated the problem where an Optional is useful and has that “expose your datatypes in your object names” vibe that I miss from old Win32 code. (Just like I miss buffer underflows when I burn CDs.)

Spring JDBCTemplate and Empty Results

I recently started using Spring’s JdbcTemplate, and found myself writing this:

Yes, an SQL query that results in an empty set is an Exception. To quote a StackOverflow: answer “Now the correct way is not to catch this exception or EmptyResultDataAccessException, but make sure the query you are using should return only one row.”

So, rather than use your database to store data and then query it for relationships, you should know the relationships in advance. And if you don’t, let the app crash with an uncaught exception.

Does a query returning an empty set “disrupt the normal flow of the program?”

In the case of the SQL query, just no. Never. Absolutely not. Why does EmptyResultDataAccessException exist? In what world does an empty result “disrupt the normal flow of the program?”

Let’s look at another snippet of code in the same program, using the same Spring object:

In this case, I’m querying for a list. If the result set is empty, the return is an empty list.

So, I’d have to say that an empty result doesn’t disrupt the normal flow of the program. EmptyResultDataAccessException is enforcing an opinion, not communicating an error.

Java is a verbose and often noisy language. Let’s try to not make it worse with unneeded try/catch blocks.

The Protocols of the Elders of Facebook

So last week I gave you some tips on how to protect your data on Facebook. I also threw in a few asides on how I look at Facebook, the information it captures, and how it might have affected the 2016 election.

On The Media did a show about this last week. They interviewed Antonio García Martinez, a former product manager at Facebook who ran their ad targeting development, about what Cambridge Analytica might or may not have been capable of. He mentioned one of his tweets that summarizes my initial reaction to the story quite succinctly.

We have read and heard many theories about what was the one-thing-that-led-to-Trump: Comey’s initial announcement about the email investigation, Comey’s second announcement just before the polls opened, fake news!, the hours of free coverage the cable networks gave Trump (the most believable of the bunch,) Hillary’s (alleged) failure to reach out to people in the rust belt, Bernie not stopping his primary challenge soon enough, other things I must be forgetting, and now this.

Facebook ad targeting and Cambridge Analytica’s “psychographic modeling” are not as sophisticated as CA made it out to be. They were selling a product, and I know this is hard to believe, but they lied about what their software could do. It looks like the even Trump’s team of “the best people” didn’t believe it and gave it a pass.

Facebook’s data isn’t really that deep. It’s our personal information, and it’s worth protecting, but it’s just not as valuable as CA made it out to be.

According to Martinez, what Trump’s team really did with Facebook was exploit people’s timelines with clickbait. They got people to click on things with inflammatory rhetoric and “fake news.”

They also exploited Facebook’s ability to correlate lists of people gathered outside of the platform with users inside Facebook.

Did any of this win the election for them? No.

The interview is here. It’s worth a listen.

 

Let’s face it; there is no one thing that led to Trump in the White House. The groundwork was already there when he ran, and that’s what we need to look if we really want to start winning elections and eliminating what he represents.

The rest of the episode is worth a listen, as is the podcast most weeks.

 

 

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑