Lord Crc
Re: Exceptions vs Error codes

Re: Exceptions vs Error codes

In article <✉>
	Lord Crc <✉> wrote:

> On Thu, 16 Aug 2001 23:45:52 +0100, Barry Kelly <✉>
> wrote:
> >In article <✉>
> >	Lord Crc <✉> 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: NNQ - Quoting Style in Newsgroup Postings
FYI: Phrase searches are enclosed in either single or double quotes
Originally created by
Tamarack Associates
Tue, 07 Feb 2023 04:50:14 UTC
Copyright © 2009-2023
HREF Tools Corp.