On Jul 31, 1:41 am, Zsolt Vasvari zvasv...@gmail.com wrote:
But I am curious why you're serializing to JSON but not sending or
saving it anywhere, unless I'm misunderstood your previous message?
I am storing JSON encoded objects in the Activity state in
onSaveInstanceState(). It's used by
On Jul 31, 12:47 am, Indicator Veritatis mej1...@yahoo.com wrote:
But one of the main points of Eckel's rather negative analysis of the
checked/unchecked distinction is -precisely- that it lends itself to
the abuse you mention. That is WHY no language since Java's invention
has chosen to
Why wouldn't you just serialize the members of your object(s) directly
to the Bundle you're being given in onSaveInstanceState()?
- encapsulates the serialization
- no worrying about name collisions
- support for collections of objects
- I am also planning on using the JSON seralized objects as
On Jul 30, 4:51 pm, Zsolt Vasvari zvasv...@gmail.com wrote:
By the way, the whole JSONException stuff is foobar-ed:
There is a way to avoid JSONException to be thrown by using the opt*
methods for reads, which I am doing now as I know that I created the
data and it must be there. But,
But one of the main points of Eckel's rather negative analysis of the
checked/unchecked distinction is -precisely- that it lends itself to
the abuse you mention. That is WHY no language since Java's invention
has chosen to repeat the experiment. And sure enough, the problem
really is not as bad in
But I am curious why you're serializing to JSON but not sending or
saving it anywhere, unless I'm misunderstood your previous message?
I am storing JSON encoded objects in the Activity state in
onSaveInstanceState(). It's used by Android to restore the state of
the Activity if it was removed
On Jul 28, 3:18 am, Nikolay Elenkov nikolay.elen...@gmail.com wrote:
Pretty darn often. Every time you need to deal with file IO, connect to a
database, or call a network service. Consider a simple data access
interface. You might have a file implementation and a database
implementation with
On Jul 28, 6:40 pm, Zsolt Vasvari zvasv...@gmail.com wrote:
- Most of my checked exceptions were repackaged SQLExceptions, which
are unchecked. And it's fine to be unchecked, because if I get a SQL
error, I cannot do anything about it other than roll back my
transaction and stop the app.
I'm
I'm curious what you mean by stop the app? What are you doing to
recover, if anything?
No, let the system Force Close the app, roll back by existing SQL
transaction and let the user submit a bug report via the Error
Reporting.
Actually, this is a pretty good specific case to talk about.
By the way, the whole JSONException stuff is foobar-ed:
There is a way to avoid JSONException to be thrown by using the opt*
methods for reads, which I am doing now as I know that I created the
data and it must be there. But, there is no way to avoid catching the
JSONException on put* operations
On Jul 27, 6:35 pm, Nikolay Elenkov nikolay.elen...@gmail.com wrote:
On Thu, Jul 28, 2011 at 3:35 AM, Doug beafd...@gmail.com wrote:
On Jul 27, 1:25 am, Nikolay Elenkov nikolay.elen...@gmail.com wrote:
On Wed, Jul 27, 2011 at 5:07 PM, Doug beafd...@gmail.com wrote:
I see checked exceptions
On Thu, Jul 28, 2011 at 5:29 PM, Doug beafd...@gmail.com wrote:
On Jul 27, 6:35 pm, Nikolay Elenkov nikolay.elen...@gmail.com wrote:
On Thu, Jul 28, 2011 at 3:35 AM, Doug beafd...@gmail.com wrote:
On Jul 27, 1:25 am, Nikolay Elenkov nikolay.elen...@gmail.com wrote:
On Wed, Jul 27, 2011 at
Doug, may I point you to the JPA API, made by Gavin King and approved by the
JCP, it's based on unchecked exceptions.
Also you can read Clean Code, A Handbook of Agile Software Craftmanship by
Robert C. Martin he talks about the bennefits of using unchecked exceptions
over checked.
I agree with
You and William F. misunderstood Nikolay: he did NOT say don't use
exceptions; they are a bad idea. He said it was the DISTINCTION
between 'checked' and 'unchecked' exceptions that is botched. He is
not alone in this claim, he is in good company. Even the deservedly
famous Java expert, author and
I don't think you are listening. He gave you the links, read them.
On Jul 28, 1:29 am, Doug beafd...@gmail.com wrote:
On Jul 27, 6:35 pm, Nikolay Elenkov nikolay.elen...@gmail.com wrote:
On Thu, Jul 28, 2011 at 3:35 AM, Doug beafd...@gmail.com wrote:
On Jul 27, 1:25 am, Nikolay Elenkov
I agree with you, this flame war is losing sense, also the original poster
dissapeared years ago.
Still here. Since I posted and discovered that my checked exceptions
were masking the real issue, I've mostly removed them.
Why?
- Most of my checked exceptions were repackaged SQLExceptions,
On Jul 25, 11:23 pm, Zsolt Vasvari zvasv...@gmail.com wrote:
A checked exception is an exceptional state that you expect to happen, like
the user entering some wrong values, you check that ant throw the ckecked
exception.
No, exceptions shouldn't be used as a program flow control
On Jul 25, 9:08 pm, Nikolay Elenkov nikolay.elen...@gmail.com wrote:
By now, it's pretty much universally accepted that checked exceptions were
a bad idea. An exception is an exception, and you either handle it or you
let it propagate up the stack. The whole checked/unchecked divide is hugely
On Wed, Jul 27, 2011 at 3:18 PM, Doug beafd...@gmail.com wrote:
On Jul 25, 9:08 pm, Nikolay Elenkov nikolay.elen...@gmail.com wrote:
By now, it's pretty much universally accepted that checked exceptions were
a bad idea. An exception is an exception, and you either handle it or you
let it
On Jul 26, 11:34 pm, Nikolay Elenkov nikolay.elen...@gmail.com
wrote:
I'm sorry I missed that universal memo. Please tell me more?
Don't take my word for it, start here:
http://www.mindview.net/Etc/Discussions/CheckedExceptions
From this article:
My theory is that when someone is trying
On Wed, Jul 27, 2011 at 5:07 PM, Doug beafd...@gmail.com wrote:
By the way, when you you advocate NOT checking the return value of C
runtime functions? You'd just write to an unknown file descriptor
even after a failed call to open() and just wait for the fallout?
I never said this, and
On Jul 27, 1:25 am, Nikolay Elenkov nikolay.elen...@gmail.com wrote:
On Wed, Jul 27, 2011 at 5:07 PM, Doug beafd...@gmail.com wrote:
By the way, when you you advocate NOT checking the return value of C
runtime functions? You'd just write to an unknown file descriptor
even after a failed
Well said Doug.
For what's it worth, I'd be voting Nikolay off my development team.
Some people just don't get it.
And it makes it worse for the rest of us as we pick up their pieces.
William
On Jul 28, 4:35 am, Doug beafd...@gmail.com wrote:
On Jul 27, 1:25 am, Nikolay Elenkov
On Thu, Jul 28, 2011 at 9:04 AM, William Ferguson
william.ferguson...@gmail.com wrote:
Well said Doug.
For what's it worth, I'd be voting Nikolay off my development team.
I wouldn't want to work for you anyway :)
Some people just don't get it.
I agree. Some people just refuse to see
On Thu, Jul 28, 2011 at 3:35 AM, Doug beafd...@gmail.com wrote:
On Jul 27, 1:25 am, Nikolay Elenkov nikolay.elen...@gmail.com wrote:
On Wed, Jul 27, 2011 at 5:07 PM, Doug beafd...@gmail.com wrote:
I see checked exceptions as a compile-time reminder that it's always a
good idea to handle
A checked exception is an exceptional state that you expect to happen, like
the user entering some wrong values, you check that ant throw the ckecked
exception.
No, exceptions shouldn't be used as a program flow control mechanism,
which is what your example is.
--
You received this message
OK, forget the second statement, the first one still is a valid one. If you
follow the standard you have to throw a checked exception when something
goes wrong but you expect that to happen. Like a violated FK in the DB.
On Tue, Jul 26, 2011 at 3:23 AM, Zsolt Vasvari zvasv...@gmail.com wrote:
On Jul 24, 2:20 am, Zsolt Vasvari zvasv...@gmail.com wrote:
Is onBackPressed called from a different thread perhaps? I wouldn't
have thought so, but stranger things have happened. And if that's
the case, how can I ensure that my variable is initialized. I cannot
construct it on the
What about showing the exact code that causes the trouble?
On Mon, Jul 25, 2011 at 2:22 AM, Doug beafd...@gmail.com wrote:
On Jul 24, 2:20 am, Zsolt Vasvari zvasv...@gmail.com wrote:
Is onBackPressed called from a different thread perhaps? I wouldn't
have thought so, but stranger things
The code that causes the trouble is literally like that. The object
is constructed in onCreate and the onBackPressed is just a single
method invocation exactly like I am showing.
On Jul 25, 5:26 pm, Romain Guy romain...@android.com wrote:
What about showing the exact code that causes the
Actually, I just realized how this can happen. If I get a checked
exception in onCreate(), I just display it in a pop-up, which the user
can dismiss and then press the back button and get the NPE. Now how a
checked exception can happen is another very good question, but I
don't expect help with
On Jul 25, 6:49 am, Zsolt Vasvari zvasv...@gmail.com wrote:
Actually, I just realized how this can happen. If I get a checked
exception in onCreate(), I just display it in a pop-up, which the user
can dismiss and then press the back button and get the NPE. Now how a
checked exception can
Yeah, that's what I mean by checked exeptions. But my app only throws
checked exceptions if there really is an error state, so I don't
particularly care what happens afterwards -- the app is hosed already.
I need to either:
a) provide a way for the user to e-mail me the error so I can fix it
b)
A checked exception is an exceptional state that you expect to happen, like
the user entering some wrong values, you check that ant throw the ckecked
exception.
In your case I think that your checked exception it's a hidden unchecked
exception, something like a try-catch catching an unchecked
On Tue, Jul 26, 2011 at 1:01 PM, Nick Risaro nris...@gmail.com wrote:
A checked exception is an exceptional state that you expect to happen, like
the user entering some wrong values, you check that ant throw the ckecked
exception.
In your case I think that your checked exception it's a hidden
+1 to that, I fight every week or so with my co-workers trying to convert
them but they insist on work with checked exceptions :(
On Tue, Jul 26, 2011 at 1:08 AM, Nikolay Elenkov
nikolay.elen...@gmail.comwrote:
By now, it's pretty much universally accepted that checked exceptions were
a bad
By now, it's pretty much universally accepted that checked exceptions were
a bad idea. An exception is an exception, and you either handle it or you
let it propagate up the stack. The whole checked/unchecked divide is hugely
artificial.
OK, not wanting to start a flame war, but that's not
On Tue, Jul 26, 2011 at 2:24 PM, William Ferguson
william.ferguson...@gmail.com wrote:
By now, it's pretty much universally accepted that checked exceptions were
a bad idea. An exception is an exception, and you either handle it or you
let it propagate up the stack. The whole checked/unchecked
Sounds like it might be possible that onBackPressed can get called
before onCreate in some circumstances where the device is being slow?
If that is at all a possibility, maybe you should check for null in
onBackPressed! :-)
Doug
On Jul 23, 4:00 pm, Zsolt Vasvari zvasv...@gmail.com wrote:
I am
Is onBackPressed called from a different thread perhaps? I wouldn't
have thought so, but stranger things have happened. And if that's
the case, how can I ensure that my variable is initialized. I cannot
construct it on the decleration as the object depends on the intent
passed in to the
40 matches
Mail list logo
