[cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null?

[ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.sy... ] Martin Andersson edited comment on CDI-565 at 10/7/15 5:11 PM: --------------------------------------------------------------- I'm not sure I fully understood you on that "dropping behavior"-thing. NPE:s is kind of what I try to advertise here =) {{null}} is and will always be a valid candidate to represent the absence, or lack of, a value. *YES*, we all agree that it is easy to misuse {{null}} and {{null}} should be avoided if we so can. My point is definitely not that {{null}} is a god sent gift. Please reread my comments and see if you can answer the questions I asked, for example, what is the difference between {{Map}} and the CDI container (when it comes to dependency lookup)? Also compare {{EntityManager.find()}} from the JPA specification which I believe is another comparable interface. Everything is an API. I don't understand this notion really or how it relates to the topic of discussion. I googled the CDI specification, {{null}} return values are used everywhere. Would you like to advocate that we setup tens of new exception types into our type system instead? Speaking of API:s, I would appreciate an {{Optional}} return type from a service only if it is conceivable and often enough the case that no return value is present. For example: {{tryCatchAFish()}}, {{getLotteryWinner()}}. Or, if it is conceivably so that the client doesn't bother about the presence of the value. For example: {{myDataSource.getSomeData().ifPresent(someValueContainer::setThatField)}}. I myself overused {{Optional}} once it was out in JDK 8, singing praise to Jesus every minute of the day. Only to discover that my overuse of it introduced complex boilerplate code. Eventually I got so lazy that I dereferenced those optionals anyway ({{Optional.get().doSomething()}} and so it was only a matter of time before I found myself back in square one. But this time, not only did I have NPE:s, all my clients had to make an extra method call all over the place for no apparent gain. More than anything else, I learnt by my own mistake that if a parameter is optional for the client, then accept {{null}}. Don't force the clients to type {{Optional.empty()}} instead of the oh so simple blueish keyword {{null}}. Null as parameters make the life easier for the implementations too. Also, if you know a "modern language" that had any success avoiding {{null}}, please let me know. That would be interesting. For example, how would I create a new 10 element array? Am I required to have all ten elements right of the bat? Guys, what is the most intuitive thing to do here? Why do you believe that the dependency lookup should have different semantics than {{Map.get()}}? was (Author: martin.andersson): I'm not sure I fully understood you on that "dropping behavior"-thing. NPE:s is kind of what I try to advertise here =) {{null}} is and will always be a valid candidate to represent the absence, or lack of, a value. *YES*, we all agree that it is easy to misuse {{null}} and {{null}} should be avoided if we so can. My point is definitely not that {{null}} is a god sent gift. Please reread my comments and see if you can answer the questions I asked, for example, what is the difference between {{Map}} and the CDI container (when it comes to dependency lookup)? Also compare {{EntityManager.find()}} from the JPA specification which I believe is another comparable interface. Everything is an API. I don't understand this notion really or how it relates to the topic of discussion. I googled the CDI specification, {{null}} return values are used everywhere. Would you like to advocate that we setup tens of new exception types into our type system instead? Speaking of API:s, I would appreciate an {{Optional}} return type from a service only if it is conceivable and often enough the case that no return value is present. For example: {{tryCatchAFish()}}, {{getLotteryWinner()}}. Or, if it is conceivably so that the client doesn't bother about the presence of the value, he's sole intent is to pass it around somewhere. For example: {{myDataSource.getSomeData().ifPresent(someValueContainer::setThatField)}}. I myself overused {{Optional}} once it was out in JDK 8, singing praise to Jesus every minute of the day. Only to discover that my overuse of it introduced complex boilerplate code. Eventually I got so lazy that I dereferenced those optionals anyway ({{Optional.get().doSomething()}} and so it was only a matter of time before I found myself back in square one. But this time, not only did I have NPE:s, all my clients had to make an extra method call all over the place for no apparent gain. More than anything else, I learnt by my own mistake that if a parameter is optional for the client, then accept {{null}}. Don't force the clients to type {{Optional.empty()}} instead of the oh so simple blueish keyword {{null}}. Null as parameters make the life easier for the implementations too. Also, if you know a "modern language" that had any success avoiding {{null}}, please let me know. That would be interesting. For example, how would I create a new 10 element array? Am I required to have all ten elements right of the bat? Guys, what is the most intuitive thing to do here? Why do you believe that the dependency lookup should have different semantics than {{Map.get()}}? -- This message was sent by Atlassian JIRA (v6.4.11#64026)