Some days I feel like code review is an exercise in educating developers. Nowhere is that clearer than in Java exception handling. Almost nobody understands this. When I’m interviewing software engineers, I pretty much never ask about exceptions because it’s an almost 100% guaranteed fail. If I’m being interviewed and I’m asked about exceptions, I have to play the meta game where I assume that my interviewer believes things that aren’t true, and I tailor my response to fit their misconceptions. Mostly I do that by focusing on the syntax and behavior without covering the semantics and proper use of exceptions. Effective Java comes closer than most to correctly explaining which exceptions you should use when, but even Bloch doesn’t quite stick the landing.

Today after yet another round of back-and-forth code review comments where I once again had to explain to an otherwise experienced developer how exception handling is supposed to work, I got the bright idea to ask Gemini, Google’s machine learning chatbot, what it thought. It gave me a better answer to the question than most programmers do; but it still made two fundamental mistakes, one of commission (saying something that isn’t true) and one of omission (leaving out an absolutely critical point). See if you can spot the mistakes.

This entry was posted on Friday, February 21st, 2025 at 8:47 am and is filed under Java. You can follow any responses to this entry through the Atom feed. You can skip to the end and make a comment. Pinging is currently not allowed.

Assumptions are an underused feature of modern testing frameworks that should be more widely known. Briefly, an assumption verifies that conditions are right to execute the test. An assertion verifies that the test passes. If an assertion fails, the test failed, and we know the code is broken. If an assumption fails, the test was not run and the code may or may not be broken.

This entry was posted on Saturday, February 1st, 2025 at 7:54 am and is filed under Java, Testing. You can follow any responses to this entry through the Atom feed. You can skip to the end and make a comment. Pinging is currently not allowed.

Here’s the coverage report on a recent PR of mine:

All modified and coverable lines are covered by tests ?

    Comparison is base (a765aef) 85.95% compared to head (fe02e1b) 85.95%.

Additional details and impacted files

@@            Coverage Diff            @@
##             master     #546   +/-   ##
=========================================
  Coverage     85.95%   85.95%           
  Complexity     3480     3480           
=========================================
  Files           230      230           
  Lines          8225     8225           
  Branches        960      960           
=========================================
  Hits           7070     7070           
  Misses          865      865           
  Partials        290      290           

Precisely identical. What happened? Did I change a comment? Well, no. In fact I added tests for
situations that were not currently covered, so why didn’t coverage increase?

This entry was posted on Sunday, December 31st, 2023 at 9:29 am and is filed under Java, Programming. You can follow any responses to this entry through the Atom feed. You can skip to the end and make a comment. Pinging is currently not allowed.

Reason 1: Mocking.

unittest.mock, Python’s mocking framework is so much more powerful than EasyMock, Mockito, or any other Java mock framework I’ve ever used. You can replace any method you like with essentially arbitrary code. No longer do you have to contort APIs with convoluted dependency injection just to mock out network connections or reproduce error conditions.

Instead you just identify a method by name and module within the scope of the test method. When that method is invoked, the actual code is replaced with the mock code. You can do this long after the class being mocked was written. Model classes do not need to participate in their own mocking. You can mock any method anywhere at any time, in your own code or in dependencies. No dependency injection required. You can even mock fields.

By contrast Java only lets you mock objects (not methods) and only when you have an available API to insert the mock in place of the real thing.

Reason 2: None is its own type.

This entry was posted on Sunday, December 10th, 2023 at 2:02 pm and is filed under Java, Programming. You can follow any responses to this entry through the Atom feed. You can skip to the end and make a comment. Pinging is currently not allowed.

Happy 20th Birthday Java! Next year I’ll buy you a drink. InfoWorld has published some of my thoughts on the occasion, “Java at 20: How it changed programming forever”.

This entry was posted on Thursday, May 21st, 2015 at 6:21 am and is filed under Java. You can follow any responses to this entry through the Atom feed. You can skip to the end and make a comment. Pinging is currently not allowed.