The transaction pattern and the feature badly missing from exceptions.

Exceptions are the best thing since sliced bread.  If you use them properly, you can write code of much higher quality than without them.  I think of the old days before exceptions, and I wonder how we managed to get anything done back then.  There is, however, one little very important thing missing from implementations of exceptions in all languages that I know of, and it has to do with transactions.

At a high level, exception handling looks structurally similar to transactional processing.  In both cases we have a block of guarded code, during the execution of which we acknowledge the possibility that things may go wrong, in which case we are given the opportunity to leave things exactly as we found them. So, given this similarity, it is no wonder that one can nicely facilitate the other, as this sample code shows:

Transaction transaction = transactionable.newTransaction();
try
{
    ...
}
finally
{
    transaction.close();
}

Note that the transaction illustrated above is a simple type of open-close transaction, not a database-style transaction. Database-style transactions are a bit more complicated, because they cannot be just closed, they need to be either committed, or rolled back. The collaboration between exception handling and database-style transactional processing is just slightly more involved:

Bug reporting: a checklist.

Here is a check list for creating useful bug reports:

1. Before reporting, make sure that you are using the latest version of the software.
2. Before reporting, play around with the bug to identify it with at least a bit of accuracy.
3. Report through the proper channel, usually an issue tracking system.
4. Make sure that the bug has not already been reported.
5. Invest some time to find a proper title for the bug.
6. State the name of the product in which you found the bug.
7. State the version of the product in which you found the bug.
8. Describe your environment (Operating System name and version, etc)
9. List the steps to reproduce the problem.
10. State the "actual result" of following the steps.
11. State the "expected result" of following the steps.
12. State the reproducibility of the bug. (Or your best estimate of it.)
13. Stick to the facts.
14. Address only one bug per bug report.
15. Include any useful attachments.

Here is a slightly more detailed discussion of each one of the above items:

IntelliJ IDEA feature request: editor actions for moving the caret left & right with Column Selection.

I just submitted a feature request for IntelliJ IDEA.

It can be found here: https://youtrack.jetbrains.com/issue/IDEA-132626

Feature request: editor actions for moving the caret left & right with Column Selection.

It is a fundamental axiom of user interface design that modes kill usability. Having to enter a special mode in order to accomplish something and then having to remember to exit that mode in order to accomplish anything else is bad, bad, bad user interface design, at least when there is even a slight chance that the same thing could be achieved without a special mode. (Think of VI for example: it is the lamest editor ever, and almost all of its lameness is due to the fact that it relies so heavily on modes.)

Unfortunately, programmers tend to think a lot in terms of modes, so the first time the user of an editor asked the programmer of that editor for the ability to do block selection ("column selection" in IntelliJ IDEA parlance) the programmer said "sure, I will add a new mode for this." That's how problems start.