having been a Java developer for a decade, i understand what you mean. however, the Java environment itself has no problem generating informative error messages for exactly those kernel error type situations you describe. in fact the Java environment doesn't just provide good error messages, it provides good exception class granularity, so an application can determine a good user friendly message based on the *class* of the exception. examples would include -
java.net.UnknownHostException java.net.ConnectException java.net.SocketTimeoutException -- etc. the android error situations i'm talking about are not even close to this. the network connection error i specified is an android permissions error, which is a long way above the kernel. but still, android only sees fit to provide "unknown error", which i'm sure you agree, given the context, could be a lot better. ideally there would be an android.net.PermissionDeniedException, accompanied with a message that told the developer which permission was denied. this would indicate rather more clearly the nature of the problem and its solution, and then there would be less FAQ list traffic etc. the same applies to the MediaPlayer issue. i know that the low-level stuff worked, because my server reported that the entire file was transmitted successfully. something inside android decided that the content wasn't acceptable, and then decided not to report the details of the problem for reasons best known to itself. in fact, apart from an inconclusive clue in the release notes, i still don't know why MediaPlayer won't play a file from an http: URL that it is perfectly happy playing via a file: URL. looking at the android.jar file, i see only a handful of android-specific exceptions. encouragingly i see a good few database ones, but only one network-related one, and a couple of util ones which are suitably vague. in fact in all i see only 30ish android exceptions in all, compared to pages of classes off java.* and javax.* etc. java is a very voodoo-free platform-neutral development environment with many advantages over the elephant traps of native development, and is unique among environments for having a compatibility suite that VM developers must pass in order for their products to be considered Java. however developers of class libraries must play ball by continuing developer-friendly Java traditions, and friendly error messages, not to mention a high degree of error class granularity, are some of those. to ignore those traditions is to undermine the effectiveness of the Java platform as a whole. Google might be new to Java and to mobile, but many people in this sphere, including me, are new to neither. best regards J >It is true that the messages should be better, but usually they aren't >very good because it's not as simple as "somebody knew but decided not >to tell." For example, in the case of trying to connect to a socket: >the connection request is rejected deep down in the kernel, and by the >time it even gets to the native networking calls those details have >been lost. > >Plus, most of these poor error messages are usually a result of >problems in native code, which uses error codes, which often aren't >that descriptive. So creating descriptive error messages means going >through and defining unique error codes for each interesting error >case, and then mapping those to strings when the exception is being >generated. > >Again, I am not saying that opaque error messages are good, it's just >often a fair amount of effort to actually generate code messages. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---