Board index » delphi » Re: compress a TJPEGImage in a THREAD ?? Help !

Re: compress a TJPEGImage in a THREAD ?? Help !


2003-08-05 03:47:50 PM
delphi260
"Danny Thorpe" <XXXX@XXXXX.COM>writes
Quote
There is no clean-up required for a string concat that fails because of an
out-of-memory exception.
If you are advocating that every statement that might possibly someday
raise
an exception in a catastrophic situation should always be wrapped by an
exception handler, you've missed the point, missed the planet, and most of
the galaxy.
I'm not. Please don't forget that this isn't even my mother language.
Nevertheless, I am convinced my point was obvious. *If* you really didn't get
my point, reread, or better still, let's just drop it.
Quote
...to the high-level code...
We've discovered yet another point of dissagreement. I think error
conditions are to be handled at the deepest call level that can handle them.
You're right in saying lots of them should result in feedback to the user,
in many designs, but that is not at all a general case.
Here's an example. I have written a library of TGraphic descendants, and a
demo image browser app. (Who hasn't?) I decided that, since what the app
offers is browsing through images, primarily, there should be no error
messages poping up. I have decided my image viewer component should display
the error messages on its canvas instead, so as to allow the user to simply
keep on browsing instead of clicking away all these anoying popups.
The way I make things easy to use, without checking error conditions after
every operation on the TGraphic descendants, is by having them remember
their error code. You can simply do something like
var
m: TAsGraphicPng;
begin
m:=TAsGraphicPng.Create;
m.LoadFromFileT(...);
m.RGBGammaCorrectT(...);
m.ResampleT(...);
if m.ErrLog then
...
The 'T' suffix means don't raise exceptions, don't return error codes, don't
anything except remembering the error state internally. Next, when that's
convinient, I can check for error state with ErrLog.
Although the same kind of error handling could of course be done with
exception handling inside the TAsGraphic methods, I believe the system
'grew' out of my concern for errors that in turn 'grew' out of their
visibility in the form of error returns.
Here's another example, in the same realm. Ever wanted to look at tags of a
partially corrupt TIFF? Exception-handling advocats often can not even open
the corrupt TIFF at all. Some highest level of exception handling pops up
the message. My TAsGraphicTiff object opens the pages it can open, instead,
if the highest level structures inside the TIFF aren't too badly messed up,
and corrupt pages of type TAsGraphicTiffPage remember their error state.
It's no problem though to browse to a corrupt page in another app of mine, a
TIFF tag viewer, to see what is nevertheless left of the tags.
That is what I call good error handling, 'putting out the fire', as you put
it, as low as possible. I would like to see you implement the same level of
functionality with your two-level exception handling habit.
Quote
People are lazy.
Are they?
Quote
Nobody ever checks the function
result of every API call, and its even rarer that the code that checks the
result communicates it appropriately to the outside world.
Mine does check. Isn't that the first thing you learn at school these days?
Or I could just say 'It's not foolproof'. But that would not be much of an
answer, would it?
Quote
It's also worth pointing out that exceptions are hard-wired into the .NET
architecture. You can not run a .NET application without exceptions.
Yeah, modern habits often seem to be more to your liking than mine, I agree.
However, I would like to see if this new M$ money-making scheme (.NET) is still
around in say 5 years or so.
Quote
Function result error codes are a "fire brigade" where every function in
the
call chain is responsible for passing the "bucket" up the chain with the
hope of putting out the fire. When all the code in the system is written
correctly, this system can work, but if only one function in the chain
fails
to pass the bucket correctly, the entire system falls apart and the house
burns down.
It's not foolproof, then?
Quote
"I will bend like a reed in the wind"
"Use the source, Luke!"
Are these (modified?) StarWars quotes? In that case, we've found another
point of dissagreement. I am more of a StarTrek fan. :-) But please, let's
not discuss that preference next.
Quote
If we keep going at this, we should at least charge admission. ;>
Yeah well, just imagine trying to do your part of this conversation in
Dutch. that is my mother language. I we were neighbours, and we spoke the
same language, I would invite you to have a bear of this instead. But we aren't,
are we?
The problem with this conversation is that we're covering way too much
ground. In a sense, this is a clash of the 'new' and 'old' school of
programming. Such a clash cannot get resolved.
Joris
 
 

Re: compress a TJPEGImage in a THREAD ?? Help !

"Nils Haeck" <XXXX@XXXXX.COM>writes
Quote
Popup messages are awful and show off bad programming skills :) That's
indeed a viable reason to use Try..Except: get rid of 'em before they
reach
the user.

By the way, I also made an image viewer, indeed who has not hehe. Though
the
more file formats you try to support the worse it gets.. Some file formats
can only be read with completely independent DLL's where you do not have
any
insight in error handling. The thing can crash or pop up messages without
any control from the main application.
I don't use any DLL's. I hate DLL's. The only third party stuff I use, is a
modified version of LibJpeg, LibPng and LibTiff. All of these are enhanced
for proper error handling, for interfacing with Delphi memory managment,
etc, are next compiled into .obj files with the Builder, which Delphi links
fine into my single exe. (As far as LibTiff and LibPng is concerned, I don't
even need to handle exceptions because I can feed back errors the good
oldfashioned way. I only need it in LibJpeg.) That solves the need for
DLL's, and ensures that I have control over everything, including error
handling. Other file formats are supported with my own home-brewn codecs,
coded up as native Delphi ObjectPascal.
Quote
A bear? Don't you mean a beer?
Oh, is that how you spell it? Anyway, I am sure it was obvious what I meant
to you at least, seeing you're Dutch too. ;-)
BTW, I am not at all rejecting OOP itself, in fact, I think it is very
important, object-oriented design is the backbone of any large project, and
I do love to code in ObjectPascal.
Joris