Funny, this was a request from me about 6 years ago when we discuss possible improvements for the tMap with the product management - nothing happens!
Sorry to say, no there is no easy way. The only chance you have is to run the job in the studio and if the Exception happens here the code line in the stacktrace is correct and you can see where it happens.
General speaking: Check all parts where a nullable number typed incoming field is mapped to an output field which is not nullable. Check if you use expressions with methods on fields or variables. Please check also joins, the comparison of field content is often a call to a equals method internally and this can cause NullPointerExceptions.
Funny, this was a request from me about 6 years ago when we discuss possible improvements for the tMap with the product management - nothing happens!
Sorry to say, no there is no easy way. The only chance you have is to run the job in the studio and if the Exception happens here the code line in the stacktrace is correct and you can see where it happens.
General speaking: Check all parts where a nullable number typed incoming field is mapped to an output field which is not nullable. Check if you use expressions with methods on fields or variables. Please check also joins, the comparison of field content is often a call to a equals method internally and this can cause NullPointerExceptions.
If you like you can post here the stack trace and also the code lines around the line mentioned in the stack trace. We could analyse this and tell you what went wrong.
Many thanks @Jan Lolling , i'd had such inconsistent results with the line numbers before that I've stopped relying on them. With your help I was able to track it down to a typo on 2 very similarly named columns where one was being used in the other but was in fact null
