Prevent NPE and report missing dependency instead

[EddyVerbruggen]

While generating d.ts files for the Mapbox SDK I ran into a NullPointerException I couldn't make sense of until I debugged the generator.

It turned out I had to provide numerous dependencies to make it work, but I didn't want those to be part of the resulting d.ts file..

So I've now made sure the generator doesn't choke on these and logs them to the console. If the developer cares about any of those missing classes he can lookup the related dependency (library) and rerun the generator.

[petekanev]

@EddyVerbruggen I like the changes, verbosity is definitely something the generator could use, especially where show blockers are concerned.

I am not sure however that the process should continue, instead of exiting, since missing a type will almost all the time mean that you will end up with incomplete and incorrect definitions that will most likely be uncompileable (yes, I just made up a word :D)

[EddyVerbruggen]

Fair point. In this particular case I didn't care about compilability (ha!), just wanted to have a bit of TS support while editing a plugin, and manually referenced the ts.d file when needed.

Perhaps make it stop by default and allow the user to override? In any case, logging the missing class is the main reason this PR was submitted ;)

[petekanev]

@EddyVerbruggen my main concern is that even if you use the typings generated thus far to call to native functionalities, the TypeScript compiler will still break with invalid d.ts's .

[EddyVerbruggen]

Clear. Btw I now remember the reason I did this in the first place: I couldn't find the right way to invoke a certain function in the Mapbox SDK and wanted to know how it was exposed to JS by the metadata generator so I could call it correctly.

[roblav96]

@Pip3r4o @EddyVerbruggen I must agree with Eddy on this one. The very first thing I do before compiling a new dependency is generate the declarations for it. I've come across this error many times in the past and this simple modification helps determine the missing .jar lib is missing.

I've now been including the following .jars for every declarations I'm creating:

java -jar dts-generator.jar \
-input android24.jar \
-input android-support-v4.jar \
-input android-support-v7-appcompat.jar \
-input okio-1.11.0.jar \
-input okhttp-3.5.0.jar \
-generate-multiple && \
echo 'HELLZ YEAH!!! :D'

[petekanev]

And we are back at it a year later.

@EddyVerbruggen I see that the changes only concern classes not found while generating interface typings. Do you think the same exceptions can be throw when traversing classes? Would you care about making an addition to the PR to address that as well?

[EddyVerbruggen]

Hi @Pip3r4o!

It looks like there are already some null checks for non interface types, and I haven't encountered a problem with those yet, so perhaps it's sufficient to keep it this way. We can always add another check, right? :)

[petekanev]

@EddyVerbruggen I'll run some libs through and see if there's going to be any need of additional checks. Thanks!