Marco Faella

+ Follow
since Dec 19, 2019
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Marco Faella

Hi Rafael, thanks for your answers.

As an educator, I think puzzles and challenges can be great learning aids,
I'll be sure to pick up your book.

6 months ago
Questions for Java Challengers' author Rafael del Nero:

Hi Rafael:

If you know the Java Puzzlers book, how does your book relate to it?

Why did you decide to self-publish rather than go with a traditional publisher?

6 months ago
Congratulations and happy reading!

The book forum (aka livebook) is available for interacting with me:

Exceptions should be caught at the level where the appropriate corrective action can be taken.

Corollary: an exception should never be caught by the method that threw it. If it threw it, by definition it doesn't know how to fix it.

If no corrective action is possible, catch it at the level when such impossibility can be ascertained (probably close to your "main" or entry point)
and log it and/or inform the user, as appropriate, before exiting.

In the book I work a lot with exceptions in chapter 5 in the context of reliability,
focusing on when, why, and what type of exceptions to throw.

Let's put it this way: the longer your toolchain, the less likely your software is to survive (long-term).
You may win in the short term, by getting the system to work in less time,
but your long-term destiny will be tied to more third-party products/frameworks.

As to GWT in particular, Tim's reply seems spot on.


Indeed, that's the idea.
Another reason is that I tried to limit the amount of Java-specific content,
so that the book may be more accessible to users of other languages (particularly C#).

Hi Germán,

chapter 8 is 90% about good practices of concurrent programming,
such as deadlock prevention and immutability.

I mention various high-level Java APIs but I don't go into details.
I recommend Manning's Modern Java in Action for that.

Hi Miroslav,

in the book I mostly steer clear of specific tools, because they change often (new versions or new tools replacing old ones),
whereas the principles expounded in the book are (hopefully) long-lasting.

Regarding the software development principles you mention, I address Dependency Inversion/Injection in chapter 6.
As to the other principles, some (like Liskov's) are assumed as background info, and others (like Single Responsibility)
are easier to appreciate in the context of larger systems, compared to the small units that the book focuses on.

Hi everyone,

thanks for hosting my book!

I'll be checking the forum for your questions.


P.S. I already messed up by posting a reply twice. Then I discovered you can't delete a post. Sorry about that!
Hi Fahd,

thanks for your interest in the book and your kind words.

Indeed, the focus of the book is on a small software unit, because I think that's the ideal size to showcase and compare many different software qualities.

As you say, a real system is composed of many parts, interacting locally or over a network, perhaps as microservices.
Even though I don't address distributed systems per se, the principles of my book apply equally well to each part of the system.
Namely, each part is subject to the careful balance of software qualities that I try to illuminate in the book.

Now, I don't mean to imply that separately optimising each part will lead to a globally optimised distributed system, but it's a step in the right direction.
Any large system will need architecture-level analyses and decisions that I don't cover in the book.
In fact, I'd expect those high-level decisions to guide the unit-level design toward a balance of qualities that is appropriate to the context.