The Daily WTF: Curious Perversions in Information Technology

2026-05-20 Reply Admin

If anything goes wrong, we rollback the transaction and chuck an exception up the chain.

worse, we silently gobble the exception up, throwing only if rolling back fails!

Steve_The_Cynic · 2026-05-20 Reply Admin

RIP, transactional wholesale triple caller

So that's "Rest in Perdition" ?

2026-05-20 Reply Admin

A shocking number of people do redundant empty checks, I used to work at a place that used jQuery(back when it was semi-popular), and it was the coding standards to always check if the length was empty, and if so replace it with null.

This resulted in code like

    var $list = $("#list");
    if ($list.length == 0) {
        $list = null;
    }
    if ($list != null) {
        $list.hide();
    }

Instead of the much simpler and obvious:

    $("#list").hide();

I complained about it so often but the tech lead at the time really didn't understand how anything worked and insisted we do what he knew worked rather than trying to change things to make them better.

He was also the person who thought the observer pattern meant we should pass the list of listeners to be triggered to the observer ala:

    InventoryRepo.add(newInventory);
    InventoryRepo.save();
    Observer.trigger(Observer.Events.Inventory.Created, newInventory, [
        TriggerEtlOnNewEntityListener,
        RecalcStockListener,
        UpdateInventortCacheListener,
        ...
    ]);

It took us 2 weeks to convince him that maintaining the list of events everywhere they may be triggered is exactly the problem the observer pattern is supposed to solve, and that if we don't stop it we are no better off than before we wanted to introduce the pattern.

It was interesting to say the least.

2026-05-20 Reply Admin

Reminds me of the time I worked for a manager who was all about the latest trendy thing. If it was new and cool, it was in the stack. (And if it used to be new and cool but was now old and busted, it was still in the stack.) One of these things was NoSQL. Everybody who was anybody in those days was using a NoSQL DB, including our team. Except that the actual product was a replacement for an old MS Access app, and the data was highly relational. Of course, NoSQL is not designed for relational operations, which meant that all of the filters and joins and everything else that your typical SQL engine does really well had to happen in the application code instead. And they wondered why the system was so slow and fragile...

Barry Margolin · 2026-05-20 Reply Admin

The only time the empty check is appropriate is if you want to display/log something about the collection being empty in place of just doing nothing or showing an empty table. But if there's no else for the if, it's redundant.

2026-05-20 Reply Admin

Now you have to check whether there's some code that was counting on Foo's not having Bar's as a sort of 'new' status!

2026-05-20 Reply Admin

It's been a long time since I had anything to do with Oracle DBs, but I'm sure this could have been easily dealt with by using insert, update & delete triggers on the appropriate table(s). If a batch process was really required, then a stored procedure would do the job with just one call instead of all that nonsense

2026-05-20 Reply Admin

A lot on life is just moving stuff around

Doing laundry? Move laundry into laundry basket Move laundry basket to the washing machine Move laundry into the machine Move detergent into the machine Mine the knob on the machine to the right setting Move the laundry into the dryer Move the laundry into the basket ...

2026-05-20 Reply Admin

Another problem with this code is catching 'Exception' - that's the super-class for all exceptions. Generally, you want to catch only the most specific exceptions that you can. Particularly if you actually handle the exceptions you expect properly. Basically catch(TransactionException ex) {transaction.rollback()}, otherwise any exception at all (including out-of-memory, file IO issues, null-pointer exception, idiot-using-the-computer exception) will cause the transaction to roll back. Which might be what you want, but probably isn't.

2026-05-22 Reply Admin

idiot-using-the-computer exception

Catching that one has been the holy grail of systems engineers since before C was a thing. I should know. I was there. Unfortunately we've made zero progress so far.

dkf · 2026-05-23 Reply Admin

The worst sin of all is a separate transaction for each Foo (plus the implicit one for reading the list of them), when it would be quite practical to hoist the whole thing into the database and get it to do all the updates in a single call (or at least only a few if you take the time to implement some sort of batching scheme). This code is going to be vastly less efficient than it should be, and purely through sheer incompetence.

The second worst sin is the swallowing of exceptions like that.

jeremypnet · 2026-05-27 Reply Admin

Generally, you want to catch only the most specific exceptions that you can.

In general, the trouble is that the code you run in a transaction is not limited to just throwing database exceptions. There may be other legitimate exceptions that mean you want to roll back the transaction but not necessarily terminate the program. The point of a transaction is to keep your database logically consistent: either every update you do in a transaction is applied to the database or none of the updates is applied to the database. Every exception that stops you from from doing all of the updates needs to cause a rollback.

Another reason why you would catch all exceptions is if somebody chooses to wrap any exception thrown in a RuntimeException so they then don't need to think about handling errors. This is a WTF pattern and its used in this article.

Find a Bar for This One

Leave a comment on “Find a Bar for This One”