2

I'm kind of in an impasse here.

Lets say I have module A which exposes some methods returning objets and module B that uses said methods from Module A. Module A will have situations when it will have to return Nothing.

The problem is: Of course I don't want to return Nothing. Many, many books, top-coders and heuristics will tell you. However, the use of exception is not allowed due to massive use of Module A. That would apparently kill performances.

At last, we do not want to use auto-instanciated objet and have to check inside state to know if it's in fact Nothing (like a check-null...)

What would be an alternative for Module A to expose it can return something empty (or nothing) and for everyone using it like Module B to be needed to check such case (like signed exceptions try-catch)?

Any help will be really appreaciated! I'm pretty much out of solution and I want to do something clean that will be able to evoluation without causing unwanted behaviours and errors. Thanks

--EDIT--

To close this question, project managers decided to return Nothing everywhere. They accept to have some production crash due to forgotten nothing-check... From what I gathered during this timelaps, I'd say that the best alternative would be the Try-object patern, because it forces the client to check the why is the return a boolean and how to use the call... at least on first use.

4
  • 1
    You can define and return an Option type, which is like a type-safe null. An option object either contains a value or contains no value. Before a consumer may access that data, they must check whether a value is present. This is better than null because the option wrapper type clearly documents that a value may or may not be present.
    – amon
    Oct 28, 2015 at 21:03
  • 2
    Exceptions are not a synonym for returning nothing. Exceptions are for exceptional situations, typically errors. Nothing can be a perfectly acceptable result and in such a case it should not be modeled using an exception. So, performance is not the only argument against exception here.
    – Giorgio
    Oct 28, 2015 at 21:08
  • If your method should never legitimately return null, but you end up where you can't return a valid value, an exception is the right way to go. Why do you think throwing is expensive, and have you tested that it would actually cause unacceptable performance, or are you just assuming?
    – Andy
    Oct 29, 2015 at 1:16
  • I'm not assuming, I would actualy be in favor of exceptions. But I'm restrained by decisions that have been made way over me. Nov 2, 2015 at 17:39

4 Answers 4

4

You can return either a thing or nothing, so somehow B has to know. You can return a list with 0 or 1 element, and B could, for example, treat it uniformaly. In pseudo-code:

// Inside one of B's method
foreach(x : A.getThings()) {
    this.doAction(x);
}
1
  • unfortunatly that's again a thing the client must know. I want a solution that the client is obligated to do when he uses A. Like this, there is 0% chance of someone calling A and forgetting this particularity, resulting in production crash. Nov 2, 2015 at 17:42
1

As I mentionned in an edit of the question, the try-object pattern is the best alternative to this problem.

0

One solution is to use Null Object Pattern in Module A. Instead of returning null, Module A will return another type that is a 'type-safe' representation of "Nothing".

0

What about having your methods return Nullable(Of Foo) ? At least that way the programmer writing the caller can see the ? and recognize that s/he might get Nothing returned.

Friend Shared Function GetSomething() As Nullable(Of SomeValueOrStructureType)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.