Optional injection

Tim's Avatar


29 Mar, 2012 08:51 AM

I haven't seen anything in the documentation so I'm guessing the answer is probably no but is there and way specify an dependancy as optional via metadata or otherwise?

i.e. [Inject (optional=true)]

Would it be considered a good idea even if it was?

My specific use case is:
I'm using the SignalCommandMap variant which injects the signal payloads automagically into my command. It is valid in some cases however for the payload to be null which unfortunately throws a runtime error in the injector as it is missing an object to fill the rule.

Thanks in advance,

  1. Support Staff 1 Posted by Till Schneidere... on 29 Mar, 2012 09:09 AM

    Till Schneidereit's Avatar

    Hi Tim,

    support for optional injections has only been introduced in
    Swiftsuspenders 2, which isn't officially supported in Robotlegs 1.

    That being said, you might want to check out my special build of
    Robotlegs 1.5.2 including the current beta release of Swiftsuspenders
    2 here:

    Based on all tests and feedback, this build should be fully compatible
    with the official Robotlegs 1.5.2 while giving you access to
    Swiftsuspenders 2.

    hope that helps,

  2. 2 Posted by Tim on 29 Mar, 2012 09:39 AM

    Tim's Avatar

    Hey Till,

    Thanks for the quick response. Will definitely check it out and let you know how I get on.

    Upon rereading my original post it would appear that I am illiterate... so many typos.

  3. Support Staff 3 Posted by Till Schneidere... on 29 Mar, 2012 09:49 AM

    Till Schneidereit's Avatar

    He, no worries: I understood what you were asking - and that's what
    counts, right?

  4. 4 Posted by Stray on 29 Mar, 2012 10:22 AM

    Stray's Avatar

    Hey Tim,

    the other alternative, if using Swiftsuspenders2 doesn't work out, is to use the NullObject pattern - where you make a specific class, extending the required value, which stands in for null values - the intent of that pattern being to avoid null-pointer / null-check errors.

    Generally I'd say that's a better option in this scenario anyway - because "NullUser" shows future coders (including yourself) that you really did intend this situation. It also means that a genuine null error won't be swallowed.

    So - tread with care in creating optional injections - if there's ever likely to be a scenario where you could be swallowing a meaningful error, take the NullObject route instead.

    For me, optional injections are more appropriate for scenarios like commands inside modules that may or may not be running in a certain shell, and therefore may or may not have access to a logger etc. Of course it would usually still be better to explicitly check for and provide a null implementation of the logger... but I'm sure there are use cases where it's very appropriate, but my current thinking is that they would be less dynamic conditions - your scenario being the highly dynamic end of things.

    Having said all that, until we've all had a few months to bang up against the pros and cons of using optional injections, and actually feel the joy and pain, I'm only extrapolating (which is just a fancy name for guessing).

    ymmv etc,


  5. 5 Posted by Tim on 29 Mar, 2012 02:29 PM

    Tim's Avatar

    Stray, Till thanks a lot for the prompt and well thought out responses.

    Till, your SwiftSuspenders 2 build works like a charm although the runtime error stopped occurring before I actually updated the metadata tag with the new optional parameter which may be cause for concern, perhaps the injection is a little more forgiving in 2.0

    Stray, you make some good points. The NullObject pattern isn't something I have used in anger before but will definitely consider it in future as I do favour an explicit statement of intent wherever possible.


  6. Support Staff 6 Posted by Till Schneidere... on 29 Mar, 2012 03:48 PM

    Till Schneidereit's Avatar

    Thanks for the feedback, Tim.

    I'll look into Swiftsuspenders 2 not throwing an error even without
    the 'optional' flag: That should still happen.

    And I agree with Stray: a NullObject is the better solution which I
    unfortunately forgot to mention in my first reply.

  7. 7 Posted by Tim Drew on 29 Mar, 2012 03:58 PM

    Tim Drew's Avatar

    Thanks Till,

    It does appear to be specifically related to the Signal payload injection,
    error throwing on regular properties functions as expected.

  8. Support Staff 8 Posted by Till Schneidere... on 29 Mar, 2012 04:00 PM

    Till Schneidereit's Avatar

    Ah, thanks for that info, that's interesting indeed.

    Makes me guess that nothing's wrong in Swiftsuspenders there: it now
    accepts `null` as a valid mapping value and didn't before. Seems like
    the Signals extension maps null if it doesn't find a "real" value.

  9. Ondina D.F. closed this discussion on 11 Apr, 2012 11:04 AM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac