Don’t Assert.fail() on Exception, Wrap With AssertionError Instead

Recently while updating and writing tests, I ran into a pattern:

try {
    /* Tested code here... */
}
catch (Exception e) {
    Assert.fail("Exception was thrown with message: " + e.getMessage());
}

Many times when developers are writing tests, they run into a similar situation where throwing an exception should result in a test failure. An uncuaght exception causes a test error, so the exception is caught and Assert.fail() is called to fail the test instead. The above code is certainly correct, but it also hides all the information that the original exception contained.

This is a cheat sheet showing various programming terms alongside example code (in Java) of what the terms describe. I created this document to give junior developers and interns a reference for the terms that developers often use to describe different elements of a program. The goal of this document is to allow senior developers to use technical language and be somewhat Socratic during code reviews with new programmers instead of pointing to specific lines and explaining exactly what to do. If a junior developer’s code is being reviewed and he or she is asked, “Why did you pass the obtainClass() method a String variable?”, he or she can quickly search this sheet for the unknown terms and try to answer the question. It will also help new developers to know what parts of the code senior devs are talking about—for example: obtainClass()’s method signature versus an obtainClass() method call. Rather than create an exhaustive reference, I want this cheat sheet to be brief, so I only included the technical words that I use the most during my current code reviews. However, I’m sure this document is not perfect, so if you would like to add or fix something, please write a comment explaining what could be improved and/or make the improvement yourself and send me a pull request.

Missing Links in Computer Science Curricula: Part 2.

Programmers are technical writers. Amazing programmers are amazing technical writers. From code to documentation, everything a software engineer does involves technical writing. Developers write code comments, source code, documentation (or wikis), blogs, bug reports, feature requests, questions, answers, forum posts, emails, chat messages, and more. While technical writing is not completely neglected in Computer Science curricula, its importance should be emphasized due to the sheer amount of writing that developers must produce.¹ Below I outline some guidelines, principles, and tips which I have found to be helpful for writing different technical documents during my three years as a software engineer.² The guidelines are by no means exhaustive, and like most rules, they can be broken if there is a good reason to break them. However, I’ve found that these rules help make my documentation clear, concise, and comprehensible.

Missing Links in Computer Science Curricula: Part 1.

Version Control is an integral part of software development. Allowing developers to track changes to software, version control systems give programmers the power to collaborate, discover erroneous changes, and compare versions of software. When rightly used, version control (also called source control) empowers developers to make and share complex changes without fear of losing previous implementations. Developers who use revision control can always look back on and—if necessary—revert to previous versions of the software. Unfortunately, I received two-and-a-half years of Computer Science education without hearing about version control once.

Computer science authors and professors often discuss the concepts of encapsulation, abstraction, and information hiding. These concepts are fundamental to programming, and they are required in order to manage complex systems. By encapsulating information into separate components, programmers can reason about those subsystems alone. Instead of understanding and mentally grasping the whole system at once, coders can partition systems into coherent sections. Unfortunately, encapsulation, abstraction, and information hiding are usually discussed with respect to objects and object-oriented programming (as you can see in the links above). But encapsulation is equally important in the lower-level tools of functions and methods.