> If I have that many levels of nested ifs, I work at refactoring the
> method or wrapping a whole thing to a common exit point. I feel that
> either of those options are better than the unfollowable jumping
> around catch/finally blocks.
In other words, you distort the code (and hide the normal
19.01.2011 3:39, Zsolt Vasvari пишет:
I just don't see, from an API design point of view, why File.open() or
Context.openInputFile() couldn't just return if the file
doesn't exist, instead of throwing an exception. Especially, since a
file not existing is usually not an exception, but a common
If I have that many levels of nested ifs, I work at refactoring the
method or wrapping a whole thing to a common exit point. I feel that
either of those options are better than the unfollowable jumping
around catch/finally blocks.
Doing what you are suggesting is also a sure-fire way of defeating
Well, File.open() can throw different types of exceptions. Generally
speaking, if the file doesn't exist, or is not readable(no permissions) or
the storage device itself is not available. So, just returning a null might
not help you decide how to handle different situations.
Kumar Bibek
http://te
> The problem with the below code is that your MUST use a comment to
> understand what's going on. And that's the biggest problem with using
> exceptions as flow control logic -- unreadable code as you cannot scan
> the code top to bottom and understand its flow. You end up with a
> mess of a co
Yes, I'm not happy with this solution... but moving to File.exists()
means re-introducing the issue of the file being removed from the
system between File.exists() and Context.openInputFile calls, however
unlikely.
Paul
On Jan 18, 7:39 pm, Zsolt Vasvari wrote:
> The problem with the below code i
The problem with the below code is that your MUST use a comment to
understand what's going on. And that's the biggest problem with using
exceptions as flow control logic -- unreadable code as you cannot scan
the code top to bottom and understand its flow. You end up with a
mess of a code with "f
On Jan 18, 12:50 am, Zsolt Vasvari wrote:
> > But don't ever let an exception fall through in the main thread that
> > runs your activities because your app will terminate with an
> > unfriendly "force close" dialog that users are conditioned to hate.
>
> I don't agree with this advice. How are
Good point... have modified the process such that on being able to
open the file (i.e. the filename is not yet used), it maintains the
stream and creates it right away, rather than checking, exiting the
loop and then creating the file.
Thanks for the pointer,
Paul
On Jan 18, 11:10 am, Kostya Va
The usual thing is to use atomic file open operations:
For input: Context.openFileInput()
For output: Context.openFileOutput()
Both of these either throw an exception when something goes wrong, or
return a File {Input|Output} Stream that you can read from /write to.
Same with "plain" Java: Fi
On Jan 18, 4:02 am, Zsolt Vasvari wrote:
> > Have an app that in various activities handles any number of types of
> > Exceptions, such as IOException, FileNotFoundException, SAXException,
> > etc. In some cases, I want an exception to terminate the called
> > Activity and alert the user of an err
I agree, that would be by definition an exception state, where the
normal flow (check if file exists -> write to it) has been disrupted.
I have a little file name generation routine that does make use of the
FileNotFoundException though, out of pure convenience: (pseudo-code)
while (true) {
fil
I disagree. An aversion to using exceptions is an old prejudice, and
trying to avoid their use can lead to some really ugly and buggy
code. Even the class loader (at least the Sun version) has exceptions
flying all over the place under the covers.
On Jan 18, 3:02 am, Zsolt Vasvari wrote:
> > Ha
Well, When someone deletes the file after you have created, and then you try
to write into it, then the catch block comes into picture. But, I guess,
that might not happen since the file would be locked. I am not sure though.
But just in case, that happens, don't you think, it's actually an EXCEPT
So if I check with file.exists() and before I can call open some other
process deletes the file I should always crash? That doesn't sound very user
friendly to me.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, se
> Have an app that in various activities handles any number of types of
> Exceptions, such as IOException, FileNotFoundException, SAXException,
> etc. In some cases, I want an exception to terminate the called
> Activity and alert the user of an error, in others, I can handle the
> Exception more g
> But don't ever let an exception fall through in the main thread that
> runs your activities because your app will terminate with an
> unfriendly "force close" dialog that users are conditioned to hate.
I don't agree with this advice. How are you going to fix problems if
you stick your head in t
On Jan 17, 9:35 pm, Paul wrote:
> Coming over from other languages/platforms, and just trying to get my
> head around the proper way to handle Exceptions in Android (or at a
> minimum, some advice/links on this topic).
I don't think Android offers any more or fewer challenges with
exception handl
18 matches
Mail list logo
