A) Returning null is not necessarily a programming error. Not handling null
results gracefully might be though.
B) How should it be possible to statically determine a non-trivial (dynamically
created) return value during compile time? If you want to catch typical,
statically determinable bugs using a byte code analyser, I recommend Findbugs.
--
Alexander Kriegisch
> Am 06.01.2014 um 15:50 schrieb Sean Patrick Floyd <seanpfl...@googlemail.com>:
>
>> On 06.01.2014 15:26, Alexander Kriegisch wrote:
>> You can neither match "return null" nor assignments to local variables, only
>> assignments to member variables.
>>
>> What you can do is match returning calls or executions and check their
>> results dynamically like this:
>>
>> after() returning(Object result) : execution(!void *(..)) {
>> if (result == null)
>> System.err.println(thisJoinPoint.toString() + " must not return
>> null");
>> }
>>
>> As you can see, I am only matching non-void methods because void methods
>> always implicitly return null. You can further refine the pointcut if you
>> want to restrict it to being applied to certain packages or classes or if
>> you want to match boolean methods returning false, int methods returning 0
>> etc.
> I'm aware of that, but I am looking for a way to do check statically in a
> policy enforcement aspect (at compile time).
> Detecting programming errors at runtime is not as reliable.
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
