I'd say we should throw an IllegalStateException.
IllegalStateException and not BeanManagerUnavailableException because I don't like to have too many custom Exceptions if they don't carry business information. This is clearly a non-expected and non-recoverable situation, thus a RuntimeException is excactly what we need imo. LieGrue, strub ----- Original Message ----- > From: Christian Kaltepoth <[email protected]> > To: [email protected] > Cc: > Sent: Monday, January 23, 2012 7:19 AM > Subject: [DISCUSS] BeanManagerProvider API > > Hey @all, > > yesterday I had a deeper look at the BeanManagerProvider > implementation and found something that could be improved. I created > DELTASPIKE-56 (see [1]) for this but it turned out that we should > discuss this topic on the mailing list. > > I saw that getBeanManager() may return null in some rare > circumstances. Unfortunately this forces everyone calling this method > to check the result for null. I think most code calling the method > absolutely requires the BeanManager and cannot proceed without it. > > My first idea was to add another method getRequiredBeanManager() that > doesn't return null if the BeanManager is not available but instead > throws a meaningful runtime exception. That's what Solder does per > default. Calling Solder's BeanManagerLocator.getBeanManager() without > a BeanManager being available will result in a > BeanManagerUnavailableException (see [2]). > > However Mark suggested that throwing an exception should be the > default behavior. I for myself like Mark's idea. > > What do you think? > > Christian > > [1] https://issues.apache.org/jira/browse/DELTASPIKE-56 > [2] > https://github.com/seam/solder/blob/master/api/src/main/java/org/jboss/solder/beanManager/BeanManagerLocator.java#L82 > > -- > Christian Kaltepoth > Blog: http://chkal.blogspot.com/ > Twitter: http://twitter.com/chkal >
