This plugin illustrates why applying this to the general case is a terrible idea. Here it's catching every type of exception, which is correct since we don't know whether we're running on a device that passes CTS. However, for example, if there's a permissions problem, or a problem with the GPS being busted, we have to rely on a stack trace in logcat and it won't crash. I personally prefer crashing over silent failing, since one will get caught in my debugger, and one will have me sifting through logcat and will go undetected for months. If you don't know what I'm talking about, go look at Camera or File!!!
I'm not sure what exceptions Google Maps throws, but debugging a Google Maps problem would be a nightmare since this will catch all the exceptions. You can do this at your own peril. On Thu, May 29, 2014 at 12:29 PM, Michal Mocny <mmo...@chromium.org> wrote: > Erik, > > I think it should be possible leave the platform plugin interface as-is, > and publish a plugin that does nothing but implement > reflection-based-execute. Then, plugin authors can opt to use that as a > base class for plugin development. > > I hesitate to give opinions on this topic, except to say that its also > something I've thought would be useful, but not enough of a big deal to > make a stink over it. > > Andrew also points out that there are plugins that have been published that > use this approach, i.e.: > https://github.com/wf9a5m75/phonegap-googlemaps-plugin/blob/master/src/android/plugin/google/maps/MyPlugin.java#L45-L57 > > > On Thu, May 29, 2014 at 3:01 PM, Joe Bowser <bows...@gmail.com> wrote: > >> On Thu, May 29, 2014 at 11:46 AM, Erik Jan de Wit <ede...@redhat.com> >> wrote: >> > >> >> What is the benefit of using this logic? I personally don't see any >> >> benefit, since this makes our code more complex. >> > >> > It would benefit the users as they don’t have to implement this >> boilerplate code of dispatching based on the string. And this logic will be >> then on the android side where it’s implemented once instead of each time >> one is building a plugin. >> >> Except that now every method exposed has to have a particular >> signature. I personally would rather see us use a Map as what Andrew >> suggested, and I really don't want this to happen. This is going to >> cause a lot more problems than it's going to solve since plugins that >> already throw exceptions may end up having it caught by the try/catch >> which will surround this whole thing. This is a BIG change in the >> API, and I don't think your reason justifies breaking every plugin >> that currently exists. >>
