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
-~----------~----~----~----~------~----~------~--~---

Reply via email to