In article <✉4ax.com>
	Lord Crc <✉hotmail.com> wrote:

> On Thu, 16 Aug 2001 23:45:52 +0100, Barry Kelly <✉eircom.net>
> wrote:
> 
> >In article <✉4ax.com>
> >	Lord Crc <✉hotmail.com> wrote:
> >
> >> 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.
> 
> An "EWriteError in ...." is more friendly to the users?

That's not what happens. Try this program (stick it in a ExceptTest.pas
file and compile with dcc32), and stick in a non-number in the box:


---8<---
program ExceptTest;


uses
	SysUtils, Classes, Forms, StdCtrls, Dialogs;


type
  TMyForm = class(TForm)
  private
  	FNumEdit: TEdit;
  public
  	constructor CreateNew(AOwner: TComponent; Dummy: Integer = 0);
override;
  	procedure OpenButtonClick(ASender: TObject);
  end;


constructor TMyForm.CreateNew(AOwner: TComponent; Dummy: Integer = 0); 
begin
	inherited CreateNew(AOwner);
	with TButton.Create(Self) do
	begin
		Parent := Self;
		OnClick := OpenButtonClick;
		Left := 10;
		Top := 10;
		Width := 73;
		Height := 25;
		Caption := 'Test Number';
	end;
	FNumEdit := TEdit.Create(Self);
	with FNumEdit do
	begin
		Parent := Self;
		Left := 10;
		Top := 35;
		Width := 100;
		Height := 25;
	end;
end;


procedure TMyForm.OpenButtonClick(ASender: TObject);
begin
	ShowMessage(IntToStr(StrToInt(FNumEdit.Text)));
end;


begin
	TMyForm.CreateNew(Application).ShowModal;
end.
--->8---


Take note of the message that appears on an error.

> >> When sending streams as ISAPI responses, i free the stream object 
> >> if an exception occurs. 
> >
> >Of course you do. That isn't a try..except block; that's a try..finally
> >block.
> 
> Hmmz... I did isapi modules a year ago,

I haven't, so forgive me if my expectations go awry.

> so i checked up the help on 
> TWebResponse.ContentStream and thought i must have dreamt that
> TWebResponse took ownership of the stream (hence the except and not
> finally). So i look up the code and: 
> 
> destructor TWebResponse.Destroy;
> begin
>   FContentStream.Free;
> 
> 
> so my code basically goes like this:
> 
>    jpgOut:= TJPEGImage.Create;
>    try
>       // generate jpgOut
> 
>       ms:= TMemoryStream.Create;
>       try
>         jpgOut.JPEGNeeded;
>         jpgOut.SaveToStream(ms);
>       except
>         ms.Free;
>       end;
>       Response.ContentStream:= ms;
>       Response.ContentStream.Position:= 0;

Now, I'd write this as:


---8<---
       ms:= TMemoryStream.Create;
       try
         jpgOut.JPEGNeeded;
         jpgOut.SaveToStream(ms);
         Response.ContentStream:= ms;
       except
         ms.Free;
         raise;
       end;
       Response.ContentStream.Position:= 0;
       [...]
--->8---


because I assume that whatever called this event would do the
appropriate thing in the case of an exception; if it didn't do the
appropriate thing, or that wasn't the desired response, I'd probably do
something like:


---8<---
       ms:= TMemoryStream.Create;
       try
         jpgOut.JPEGNeeded;
         jpgOut.SaveToStream(ms);
         Response.ContentStream:= ms;
       except
         on e: Exception do
         begin
           LogExcept(e);
           ms.Free;
         end;
       end;
       Response.ContentStream.Position:= 0;
       [...]
--->8---


However, it all depends on your bedrock of exception handling; that is,
what you want to do with error messages that occur during processing.


I don't know the constraints of your situation; so I can't say if it is
flawed or not.


My main point is that justified exception-swallowing try..except blocks
are pretty rare.


-- Barry


-- 
  If you're not part of the solution, you're part of the precipitate.
Team JEDI: http://www.delphi-jedi.org
NNQ - Quoting Style in Newsgroup Postings
  http://web.infoave.net/~dcalhoun/nnq/nquote.html