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 "finally" blocks peppered around to do clean up.
I just don't see, from an API design point of view, why File.open() or Context.openInputFile() couldn't just return <null> 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 occurence. On Jan 18, 11:52 pm, Paul <[email protected]> wrote: > 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) { > fileName = ... > try { > openFileInput(fileName); > } catch (FileNotFoundException e) { > // file doesn't exist, use this name > break; > } > > } -- 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
