Yes, absolutely the errors should be better detailed, mainly on the compiling and conversion phase, when you cannot insert a try catch and print the error message : (
Adriano Crestani On Oct 9, 6:53 pm, hackbod <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
