In article <3b7cdbc6$1_2@dnews> "Kristofer Skaug" <✉satserv.nl> wrote:
> "Barry Kelly" <✉eircom.net> wrote in message > news:✉4ax.com... > > > I tend to mute all exceptions in the execute block of a thread, for > > > instance (otherwise the app has a mysterious tendecy to suddenly > > > dissappear). > > > > Pre D6, yes. You must have a bed-rock of exception handling, unless you > > want all error conditions to be fatal. > > What's different about this in D6? <educate me, I've only yesterday > acquired D6 personal and didn't start using it yet>
There is a try..except that protects the TThread.Execute method; before the application would just fall off a cliff, unless you had your own one in .Execute.
> > > I often catch exceptions raised by TFilestream, so the > > > user can get a notice in a gracefull manner that the file is locked > or > > > the free diskspace is no more. > > > > There, I think that's a bad idea. > > What is a bad idea, raising the exceptions in the first place > or ensuring they're caught?
If the filesystem is full, depending on the type of application (of course), the user should be shown an error message / a log message should be written / some special-case action should be taken.
The case of "some special-case action should be taken" is pretty rare; it implies that the program is going to try and delete some files.
This rare case is the only one for which an *individual* try..except block is warranted.
The others can get along with a bed-rock mechanism.
-- Barry