1

I'm facing a problem at work on a very big system which, because of server performances and ressources, can't have exceptions managment. Instead, the system architects have decided to return Nothing when, for exemple, a database connector finds nothing. System is coded in VB.NET.

I am aware that returning and passing Nothing is normally a bad habbit for various reasons such as a violation of some of the solid principles, some noise in the code for null checks and addition of fragility because of NullPointerExceptions that can be passed-by. All that alongside the fact that returning Nothing can mean a hell lot of things (did it crash?, did it encountered an error with one of its dependencies?, was my parameters valid?...) The book "Clean code" from Robert C. Martin (or Uncle Bob) even talks about it saying it's not a good practice.

The question Alternatives to returning NULL is not only old but also doesn't give any good alternatives on what to do instead of returning Nothing.

There's also the Null Object pattern. From what I read on the subject the community seems to be divided in two camps, those who discourage its use saying it's just hiding a faulty design and those who says it's actualy a solution.

I just want to propose a clean, professional and solid solution. What would be a good alternative that implies clean codification et design while not taking too much of those precious server ressources? Since I am fairly new in the professional domain I would like to know what a guru/expert would do and how would he/she face the problem. I'm seeking

Thanks a lot (sorry, english is not primary language)

Community
  • 1
  • 1
Xavier Huppé
  • 544
  • 1
  • 4
  • 17
  • I've seen software that returns null but have a lot of logs when running on testing servers. – the_lotus Jul 23 '15 at 15:49
  • Large systems built from software that is not allowed to use exceptions are guaranteed project disasters. Just about every .NET programmer knows what it looks like, the System.Drawing namespace was built on [top of code](http://stackoverflow.com/a/2610506/17034) that wasn't allowed to throw exceptions. The .NET wrappers still throws exceptions from returned error codes, it is just that nobody knows what they mean and what they are supposed to do about it. – Hans Passant Jul 23 '15 at 17:32
  • @HansPassant "guaranteed project disasters" is what I fear the most while using Nothing as return. How would you aproach a project manager with this advice? I'm in a position of only seeing this happening and not having the power of deciding what to do. That's why I'm seeking for something else to propose. Thanks again. – Xavier Huppé Jul 23 '15 at 17:38

1 Answers1

2

As you indicated, using Null Object pattern to hide a fault is a bad idea. Here are some examples how to use Null Object properly: Null Object Pattern

In many cases, Null Object is not the right solution because it merely replaces null (Nothing) reference. You can use Special Case Pattern to carry more information and produce rich response on the client.

If neither is right, if it's impossible to produce valid object, you can choose to return an empty collection instead of object. Here are the details: Option Functional Type

Hope this helps. Keep on mind that faults should not be hidden by any objects. If operation has failed, throw an exception. But, if failed operation is a regular case (i.e. not exceptional), then try to design special cases that represent negative scenarios.

Zoran Horvat
  • 10,924
  • 3
  • 31
  • 43