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. On Oct 9, 1:45 pm, Jason Proctor <[EMAIL PROTECTED]> wrote: > i'd never have thought of that ;-) > > in the socket case, the actual exception message is as i posted. > prior to me logging the exception, OSNetworkSystem logs "unknown > socket error -1". > > in the MediaPlayer.create() case, no exception is thrown. the method > returns null to signify the error. however, the internal exception is > logged in the DDMS window, and it's exactly the message i posted. > > in both cases, some piece of Android SDK knew what the problem was, > and decided not to tell. > > i hope that nobody is going to argue *against* informative error > messages? they are a hallmark of java development - i have written > countless Swing applications with not even one question posted on a > list. > > opaque error messages just lead to endless list FAQs and delayed > applications. biggest problem with the computer industry as a whole > IMHO. > > >Wrap the issue in a try catch block and log the exception. You'll get > >much more detailed info. > > >On Wed, Oct 8, 2008 at 4:32 PM, Jason Proctor <[EMAIL PROTECTED]> wrote: > > >> dear google, any chance of better error messages from the android > >> classes? usually, the java frameworks have nice developer-friendly > >> (as opposed to user-friendly) messages in exceptions when things go > >> wrong. but it seems that with the android.* packages, errors are > >> unexpected and the message is invariably some variation on -- > > >> error code -1: unknown error > > >> -- which isn't very helpful. that's the actual error message when an > >> application tries to open a socket and doesn't have internet > >> permission. this led to numerous list threads etc which could have > >> been avoided if the piece of code discovering the problem and > >> throwing the exception had included a better message. then the > >> solution would have been obvious. > > >> i'm running into another one at the moment. if MediaPlayer doesn't > >> like the data it's presented with, it will throw during prepare(). > >> the error message i'm looking at is -- > > >> error: Prepare failed: status=0xffffffff > > >> -- which is, you guessed it, error code -1 again. there are numerous > >> possible error cases here, and the code which threw the exception > >> knew what the problem was, so why didn't it tell us? i'm going to > >> have to start another list thread on streaming http, because i can't > >> tell what the problem is. i *know* prepare() failed, how about > >> telling me WHY?? > > >> thanks in advance. > > >> j > > >-- > >~chris --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
