дык, никто не отклоняется от темы. вы утверждаете, что это верно: ну теперь по порядку. под "ваши доказательства" вы предлагаете показать вам документацию и практику применения? (возьмем Delphi7 ). ок. 1. документация от борланда. жмем волшебную кнопку Ф1 не ахти объяснение? и если не понятно, идем дальше. к хелпу мы еще вернемся. 2. более творческий пересказ Ф1 от авторов: ISBN 0672312840 (eng) ISBN 5845900166 (rus) глава 6 стр 173. ISBN 9781598220032 (eng) chapter 13 page 289 (внешка) Securing Resource Allocations The reserved word try enables us to construct two different blocks: the exception handler block and the resource protection block. The exception handler block is created with the reserved word except and the resource protection block is created with the reserved word finally. The syntax of the resource protection block in Delphi is: finally end;try In C++, the resource protection block looks like this: { } __finally { }try The exception handling and resource protection blocks are used differently and act differently. While the statements in the exception handler execute only if the statements in the try block raise an exception, the statements in the finally block are always executed, even if no exceptions are raised by the statements in the try block. If an exception occurs in the try block, the control is passed to the finally block and cleanup code is executed. If no exceptions occur in the try block, the statements in the finally block are executed after the statements in the try block. The proper way to use the resource protection block is to allocate or otherwise acquire the resource before the try block. After you have acquired the resource, write statements that use the resource inside the try block. When you're finished with the resource, you have to release it. The statements that release the resource should be placed in the finally block. try { use the acquired resource } finally { release the resource } end; { acquire the resource } The resource protection block is often used to ensure that dynamically created objects are released properly. For instance, you should always protect dynamic modal form creation with the try-finally block (see Listings 13-8A and 13-8B). Listing 13-8A: Dynamically creating a form with resource protection, Delphi version var NewForm: TForm; begin NewForm := TForm.Create(Self); try NewForm.ShowModal; finally NewForm.Free; end; end;procedure TForm1.CreateFormClick(Sender: TObject); Listing 13-8B: Dynamically creating a form with resource protection, C++ version { TForm* NewForm = new TForm(this); try { NewForm->ShowModal(); } __finally { delete NewForm; } }void __fastcall TForm1::CreateFormClick(TObject *Sender) Listing 13-9 shows an even shorter way to dynamically create a form protected by the try-finally block. Listing 13-9: Dynamically creating a form with resource protection, revisited begin with TForm.Create(Self) do try ShowModal; finally Free; end; end;procedure TForm1.CreateFormShortClick(Sender: TObject); The other difference between the exception handling and the resource handling blocks is that the resource handling block doesn't handle the exception. Thus, if an exception occurs, it will be passed to the first available exception handler. For instance, if you run the following code, the EDivByZero exception will cause the default exception handler to display the message box informing the user about the exception. begin with TForm.Create(Self) do try { raises EDivByZero because the Tag property = 0 } Caption := IntToStr(Top div Tag); ShowModal; finally Free; end; end;procedure TForm1.CreateFormShortClick(Sender: TObject); If you want to handle the EDivByZero exception (or any other exception) inside the resource protection block, you have to write a nested exception handler block. The following listing shows how to write a nested exception handler inside the resource protection block. You can also nest resource protection blocks inside other resource protection blocks or exception handling blocks. Listing 13-10: Nested blocks begin with TForm.Create(Self) do try try Caption := IntToStr(Top div Tag); except on EDivByZero do Caption := 'Tag = 0'; end; ShowModal; finally Free; end; end;procedure TForm1.CreateFormClick(Sender: TObject); ... http://books.google.ru/books?id=dOvw6h84qvwC&pg=PA289&lpg=PA633#v=onepage&q=&f=true не отличаются друг от друга и не противоречат линии "партии" Borland. и опять не то? 3. шаблоны кода (code templates) Delphi. в редакторе кода Delphi 7 ctrl + J далее жмем t, видим trycf , выбрали и enter. получаем что то такое : try finally variable.Free; end; variable := typename.Create; понятно к чему Borland клонит, а остальным ? нет? да мало что они в шаблонах написали и кто написал, "индусы" где только не работают. смотрим дальше. 4. исходники от Borland . %Delphi7%\ source\vcl. исходники режу, уменьшая размер и выбираю "интересное". не только на создание и удаление ресурсов, как говорил выше, и для "парных" методов и операций: var ... begin ... Working := TBitmap.Create; try Working.Width := EdgeWidth; Working.Height := FTabHeight; MaskColor := clOlive; ... finally Working.Free; end; ... end; procedure TTabSet.CreateEdgeParts; procedure TThemeServices.PaintBorder(Control: TWinControl; EraseLRCorner: Boolean); var ... begin ... DC := GetWindowDC(Handle); try EmptyRect := DrawRect; if EraseLRCorner then begin ... finally ReleaseDC(Handle, DC); end; ... end; function CopyConfFile(Source, Target: string): Boolean; var List: TStrings; IniIn, IniOut: TMemIniFile; begin List := TStringList.Create; try IniIn := TMemIniFile.Create(Source); try IniOut := TMemIniFile.Create(Target); try IniIn.GetStrings(List); IniOut.SetStrings(List); IniOut.UpdateFile; Result := True; finally IniOut.Free; end; finally IniIn.Free; end; finally List.Free; end; end; function TPrinter.GetPrinters: TStrings; var ... begin ... GetMem(Buffer, Count); try if not EnumPrinters(Flags, nil, Level, PByte(Buffer), Count, Count, NumInfo) then Exit; PrinterInfo := Buffer; ... finally FreeMem(Buffer, Count); end; ... end; procedure TMenuItem.AdvancedDrawItem(ACanvas: TCanvas; ARect: TRect; State: TOwnerDrawState; TopLevel: Boolean); const ... begin ... Glyph := TBitmap.Create; try Glyph.Transparent := True; Glyph.Handle := LoadBitmap(0, PChar(OBM_CHECK)); OldBrushColor := Font.Color; Font.Color := clBtnText; Draw(GlyphRect.Left + (GlyphRect.Right - GlyphRect.Left - Glyph.Width) div 2 + 1, GlyphRect.Top + (GlyphRect.Bottom - GlyphRect.Top - Glyph.Height) div 2 + 1, Glyph); Font.Color := OldBrushColor; finally Glyph.Free; end; ... end; procedure TDockTree.PaintSite(DC: HDC); var ... begin Canvas := TControlCanvas.Create; try Canvas.Control := FDockSite; Canvas.Lock; try Canvas.Handle := DC; try for I := 0 to FDockSite.ControlCount - 1 do begin Control := FDockSite.Controls[I]; ... end; finally Canvas.Handle := 0; end; finally Canvas.Unlock; end; finally Canvas.Free; end; end; procedure TCustomMaskEdit.SetCursor(Pos: Integer); const ... begin ... FSettingCursor := True; try SendMessage(Handle, WM_KEYDOWN, ArrowKey[UseRightToLeftAlignment], 1); SendMessage(Handle, WM_KEYUP, ArrowKey[UseRightToLeftAlignment], 1); finally FSettingCursor := False; end; ... end; constructor TDockTree.Create(DockSite: TWinControl); var ... begin ... BeginUpdate; try for I := 0 to DockSite.ControlCount - 1 do InsertControl(DockSite.Controls[I], alLeft, nil); FTopZone.ResetChildren; finally EndUpdate; end; ... end; procedure TStringGridStrings.Assign(Source: TPersistent); var ... begin ... BeginUpdate; Max := TStrings(Source).Count - 1; if Max >= Count then Max := Count - 1; try for I := 0 to Max do begin Put(I, TStrings(Source).Strings[I]); PutObject(I, TStrings(Source).Objects[I]); end; finally EndUpdate; end; ... end; procedure TCustomImageList.CopyImages(Value: HImageList; Index: Integer = -1); var I: Integer; Image, Mask: TBitmap; ARect: TRect; begin ARect := Rect(0, 0, Width, Height); BeginUpdate; try Image := TBitmap.Create; try with Image do begin Height := FHeight; Width := FWidth; end; Mask := TBitmap.Create; try with Mask do begin Monochrome := True; Height := FHeight; Width := FWidth; end; for I := 0 to ImageList_GetImageCount(Value) - 1 do if (Index = -1) or (Index = I) then begin with Image.Canvas do begin FillRect(ARect); ImageList_Draw(Value, I, Handle, 0, 0, ILD_NORMAL); end; with Mask.Canvas do begin FillRect(ARect); ImageList_Draw(Value, I, Handle, 0, 0, ILD_MASK); end; Add(Image, Mask); end; finally Mask.Free; end; finally Image.Free; end; finally EndUpdate; end; end; procedure TSessionList.GetSessionNames(List: TStrings); var I: Integer; SList: TList; begin List.BeginUpdate; try List.Clear; SList := FSessions.LockList; try for I := 0 to SList.Count - 1 do with TSession(SList[I]) do List.Add(SessionName); finally FSessions.UnlockList; end; finally List.EndUpdate; end; end; ну кто нам Borland, так? там диктатура. им сказали жать ctrl+J, они и давят. 5. мы за демократию. тем более, в одной финской поговорке говорится: "При достаточном количестве глаз, все ошибки лежат на поверхности" ©. http://www.delphi-jedi.org/ беру одну из частей проекта: JCL- http://jcl.delphi-jedi.org/. сырцы забираем с http://sourceforge.net/projects/jcl/ идем в каталог \source\common\ function TJclAbstractContainerBase.ObjectClone: TObject; var NewContainer: TJclAbstractContainerBase; begin {$IFDEF THREADSAFE} ReadLock; try {$ENDIF THREADSAFE} NewContainer := CreateEmptyContainer; AssignDataTo(NewContainer); Result := NewContainer; {$IFDEF THREADSAFE} finally ReadUnlock; end; {$ENDIF THREADSAFE} end; ... procedure TJclAnsiStrAbstractCollection.AppendToStrings(Strings: TJclAnsiStrings); var It: IJclAnsiStrIterator; begin It := First; Strings.BeginUpdate; try while It.HasNext do Strings.Add(It.Next); finally Strings.EndUpdate; end; end; procedure TJclAnsiStrings.LoadFromFile(const FileName: TFileName); var Stream: TStream; begin Stream := TFileStream.Create(FileName, fmOpenRead or fmShareDenyWrite); try LoadFromStream(Stream); finally Stream.Free; end; end; function TJclIntfBinaryTreeIterator.Right: IInterface; begin {$IFDEF THREADSAFE} FOwnTree.ReadLock; try {$ENDIF THREADSAFE} Result := nil; if FCursor <> nil then FCursor := FCursor.Right; if FCursor <> nil then Result := FCursor.Value else if not FOwnTree.ReturnDefaultElements then raise EJclNoSuchElementError.Create(''); {$IFDEF THREADSAFE} finally FOwnTree.ReadUnlock; end; {$ENDIF THREADSAFE} end; function TJclCompressionStreamFormats.FindCompressFormat(const AFileName: TFileName): TJclCompressStreamClass; var IndexFormat, IndexFilter: Integer; Filters: TStrings; AFormat: TJclCompressStreamClass; begin Result := nil; Filters := TStringList.Create; try for IndexFormat := 0 to CompressFormatCount - 1 do begin AFormat := CompressFormats[IndexFormat]; StrTokenToStrings(AFormat.StreamExtensions, DirSeparator, Filters); for IndexFilter := 0 to Filters.Count - 1 do if StrMatches(Filters.Strings[IndexFilter], StrLower(AFileName)) then begin Result := AFormat; Break; end; if Result <> nil then Break; end; finally Filters.Free; end; end; ... procedure InternalCompress(SourceStream: TStream; CompressStream: TJclCompressStream; ProgressCallback: TJclCompressStreamProgressCallback; UserData: Pointer); var SourceStreamSize, SourceStreamPosition: Int64; Buffer: Pointer; ReadBytes: Integer; EofFlag: Boolean; begin SourceStreamSize := SourceStream.Size; // source file size SourceStreamPosition := 0; GetMem(Buffer, JclDefaultBufferSize + 2); try // ZLibStream.CopyFrom(SourceStream, 0 ); // One line way to do it! may not // // be reliable idea to do this! also, // //no progress callbacks! EofFlag := False; while not EofFlag do begin if Assigned(ProgressCallback) then ProgressCallback(SourceStreamSize, SourceStreamPosition, UserData); ReadBytes := SourceStream.Read(Buffer^, JclDefaultBufferSize); SourceStreamPosition := SourceStreamPosition + ReadBytes; CompressStream.WriteBuffer(Buffer^, ReadBytes); // short block indicates end of zlib stream EofFlag := ReadBytes < JclDefaultBufferSize; end; //CompressStream.Flush; (called by the destructor of compression streams finally FreeMem(Buffer); end; if Assigned(ProgressCallback) then ProgressCallback(SourceStreamSize, SourceStreamPosition, UserData); end; function CompareFiles(const FileA, FileB: TFileName; BufferSize: Longint): Boolean; var A, B: TStream; begin A := TFileStream.Create(FileA, fmOpenRead or fmShareDenyWrite); try B := TFileStream.Create(FileB, fmOpenRead or fmShareDenyWrite); try Result := CompareStreams(A, B, BufferSize); finally B.Free; end; finally A.Free; end; end; function SetBitmapColors(Bmp: TBitmap; const Colors: array of TColor; StartIndex: Integer): Integer; type TRGBQuadArray = array [Byte] of TRGBQuad; PRGBQuadArray = ^TRGBQuadArray; var I, RGB: Integer; ColorTable: PRGBQuadArray; Count: Integer; begin Count := High(Colors)-Low(Colors)+1; GetMem(ColorTable, Count * SizeOf(TRGBQuad)); try for I := 0 to Count-1 do with ColorTable^[I] do begin RGB := ColorToRGB(Colors[I]); rgbBlue := GetBValue(RGB); rgbGreen := GetGValue(RGB); rgbRed := GetRValue(RGB); rgbReserved := 0; end; Bmp.HandleType := bmDIB; Result := GDICheck(SetDIBColorTable(Bmp.Canvas.Handle, StartIndex, Count, ColorTable^)); finally FreeMem(ColorTable); end; end; function GetLocalGroups(const Server: string; const Groups: TStrings): Boolean; var Err: NET_API_STATUS; wServername: WideString; Buffer: PByte; Details: PLocalGroupInfo0; EntriesRead, TotalEntries: Cardinal; I: Integer; begin wServername := Server; Err := RtdlNetLocalGroupEnum(PWideChar(wServername), 0, Buffer, MAX_PREFERRED_LENGTH, EntriesRead, TotalEntries, nil); if Err = NERR_SUCCESS then begin Details := PLocalGroupInfo0(Buffer); Groups.BeginUpdate; try for I := 0 to EntriesRead - 1 do begin Groups.Add(Details^.lgrpi0_name); Inc(Details); end; finally Groups.EndUpdate; end; end; RtdlNetApiBufferFree(Buffer); Result := (Err = NERR_SUCCESS); end; function GetInteractiveUserName: string; var Handle: THandle; Token: THandle; User: PTokenUser; {$IFDEF SUPPORTS_UNICODE} Name, Domain: WideString; {$ELSE ~SUPPORTS_UNICODE} Name, Domain: AnsiString; {$ENDIF ~SUPPORTS_UNICODE} begin Result := ''; if not IsWinNT then // if Win9x, then function return '' Exit; Handle := GetShellProcessHandle; try Token := 0; Win32Check(OpenProcessToken(Handle, TOKEN_QUERY, Token)); try User := nil; QueryTokenInformation(Token, TokenUser, Pointer(User)); try LookupAccountBySid(User.User.Sid, Name, Domain); Result := Domain + '\' + Name; finally FreeMem(User); end; finally CloseHandle(Token); end; finally CloseHandle(Handle); end; end; им также приказали жать Ctrl+J ? ну а то, смотрим: открываем окно" about... ", что в меню help. удерживая кнопку alt набираем jedi . им приказали =). продолжаем дальше или хватит? или п.4-5 фальсификация. 6. магическая кнопка Ф1 могла бы быть более информативней. но всегда есть вероятность, что понимание написанного будет соответствовать второй части известной русской поговорки : "... . Если писан, то не читан. Если читан, то не понят. Если понят, то не так!" embarcadero решила изменить ситуацию и привлечь комьюнити для пополнения EDN, на понятном языке: try…finally. try…finally. There were quite a few interesting comments made to this post from the other day that seemed to indicate that there is a little confusion out there regarding exceptions. More specifically, the try…finally construct. I’ve seen some rather interesting twists on the use of try…finally that have made me pause and wonder why it was done that way. When programming with exceptions, you always have to be aware that at nearly any point and without warning, control could be whisked away to some far-off place. In many ways you have to approach and think about the problem very similarly to how you would in a multi-threaded scenario. In either case, you always have to keep in the back of your mind two (or more in the multi-threaded case) potential code paths. The first one is easy since that is the order in which you’re writing the code statements that define the overall logic and intent of your program. The other, and often forgotten code path is the exception execution path. When an exception is raised (or "thrown" in the parlance of C++ and other similar languages) a lot of behind the scenes work is set into motion. I won’t be going into the details of exactly what is going on since that tends to be platform and language dependant. I’ll focus more on what happens from the programmers perspective and even more specifically the try…finally construct. One way to think of the try…finally block is that it is the programmer’s way of "getting in the way" of that secondary code execution path. However, it is also unique in that it also "gets in the way" of the normal code execution path. In the grand scheme of things, the try…finally block is one of the most used (and often mis-used) block types for programming with exceptions. I’d venture to say that in the typical application the ratio of try…finally blocks to try…except blocks is on the order of 100:1. But why use them at all and what are they good for? It’s all about resource management. Memory, files, handles, locks, etc… are all examples of the various resources your application uses and interacts with. The whole point of the try…finally block is to ensure an acquired resource is also properly handed back regardless of which execution path the application takes. Let’s look at some common misuses of the try…finally block and examine them more closely. var Obj: TMyClass; begin try Obj := TMyClass.Create; … finally Obj.Free; end; end; There’s a subtle problem here… Let’s follow the normal execution flow first. Control enters the try block, an instance of TMyClass is allocated and the constructor is called, control returns and the local variable, Obj, is assigned. Some operations are done with the Obj instance (the "…"), then control enters the finally block and the Obj instance is freed. So far so good, right? I mean, the memory is allocated and freed and all is well with the heap along with any other resources needed by the TMyClass instance (assuming it is a properly designed class, that is). Now let’s look at the other possible flow of control. Control enters the try block, an instance of TMyClass is allocated and the constructor is called. Here is where something can go horribly wrong. When programming with exceptions, the possibilities are nearly endless as to what can happen during the call to the constructor. The most obvious is the case where the memory manager is unable to allocate enough space on the heap to hold the instance data for the new instance. An "Out of Memory" exception is raised. Hey, but that’s OK because the finally block will get in the way of the the exception control flow, right? Yep, that’s right. So memory was never allocated, the constructor was never called, local variable Obj was never assigned, and control is passed to the finally block which contains…. uh… Obj.Free; Do you see it now? Yep, that’s right, the Obj reference was never properly set. Because of that, the call to Obj.Free; is not good for the health of your application. Chances are that another exception is going to be raised which will supercede the original exception (most likely a more fatal and nasty one). So how do we fix this? Hey I know! What if we just made sure to pre-initialize the Obj reference to nil (Obj := nil;)? Sure. You could do that, but that is just adds another line of code to your function. How can we arrange the above code to ensure that every time control is passed to the finally block regardless of which path of execution is used to get there? It’s actually very simple. Here’s the same block with that subtle change: var Obj: TMyClass; begin Obj := TMyClass.Create; try … finally Obj.Free; end; end; But now the construction of the TMyClass instance isn’t protected! It doesn’t have to be and let’s examine why. From some of my previous posts regarding exception safety and the use of Assigned, we alluded to the fact that while the constructor of an object is executing, if any exception is raised the destructor will automatically be called, the object will be freed and the exception is allowed to continue on its merry way. There are essentially two main areas were things can go wrong. The first is during the actual allocation of the memory for the instance. If the memory manager is unable to find a block of free memory large enough to hold that instance, it will raise an "Out of Memory" exception. Since the instance was never actually allocated, there is no need to ever execute the Obj.Free; line of code. Since the try…finally block was never entered, Obj.Free will never be called. The other place where things can go wrong is in the object’s constructor. In this case the memory manager allocated the memory and then control was passed off to the the constructor that would begin to setup the instance. If something fatal happened along the way there, we know from those past articles that the destructor will automatically be called and the instance memory handed back to the memory manager for later re-use. Since the object was already freed and, again, control never entered the try…finally block, the Obj.Free; line is never executed. So in both of those scenarios, there was no need to touch the local Obj variable reference since the resources associated with the TMyClass instance were taken care of. If the memory allocation succeeds, the constructor runs to completion, then control will return and the local variable Obj will be assigned after which control will then enter the try…finally block. It is only at this point that you always want to make sure the TMyClass instance referenced by Obj is freed regardless of what happens next. There are a lot of other interesting "twists" on the usage of try…finally and try…except blocks that I’ve seen over the years. The above case stands out in my mind as the most common mistake made. I’ll address some of the other cases in following posts. If you have any questions about certain common idioms and patterns that you’re not sure are exception aware, post some comments and maybe I’ll address them in future posts. There are a lot of other interesting "twists" on the usage of try…finally and try…except blocks that I’ve seen over the years. The above case stands out in my mind as the most common mistake made. - собственно так и есть. такие вот картинки из жизни, хотя можно было остановиться и в п.1, все дело в пони... , ну вы поняли =). напоследок 1. создайте проект VCL. сохраняем. 2. на форму разместите TButton , "кликнем" по ней. создается обработчик события OnClick: procedure TForm1.Button1Click(Sender: TObject); - ну или что то того. 3. используя магию копипаста доводим до вида: var t: TTest; begin //t := TTest.Create; - так верно try t := TTest.Create; // - а это нет MessageDlg('Понятно ?',mtInformation,mbOKCancel,0); finally t.Free; end; end;procedure TForm1.Button1Click(Sender: TObject); 4. повторим призыв копипаста, добавим ниже: constructor TTest.Create; begin raise Exception.Create('тест провален'); end; 5. в разделе interface добавим, известным магическим заклинанием Ctrl + C Сtrl + V constructor Create(); end; TTest = class unit Unit1; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls; type TForm1 = class(TForm) Button1: TButton; procedure Button1Click(Sender: TObject); private { Private declarations } public { Public declarations } end; TTest = class constructor Create(); end; var Form1: TForm1; implementation {$R *.dfm} procedure TForm1.Button1Click(Sender: TObject); var t: TTest; begin //t := TTest.Create; - так верно try t := TTest.Create; // - а это нет MessageDlg('Понятно ?',mtInformation,mbOKCancel,0); finally t.Free; end; end; constructor TTest.Create; begin raise Exception.Create('тест провален'); end; end. 6. не запускаем, а только компилируем. ctrl+f9 неважно, что получим варнинг - гавно случается, для настоящих "кодеров" это не повод для суеверий. Code Monkey добавят чего "следует", натыкая Excalibur-усы костыли, главное же работает. им, как говорится, "бог навстречу". 7. открываем проводник и идем к нашему файлику. 8. напрягаем мозг и угадываем, что за сообщение будет в окне. оно же точно будет. загадали ? 9. раз загадали, кликаем и запускаем. 10. ц е н о к с уважением это в другой передаче, хотя встречаются и тут
