RE: Digest for EUforum at topica.com, issue 4120
Christian Cuvier wrote:
>
>
> > What you want is error trapping and exception handling.
> >
> > I've written a library to deal with this..
> > It's not perfect, because we can't bail out of the call stack, but
> > otherwise, it's a good solution for error trapping.
>
> [snipped library partial description]
>
> > I'll share it with anyone interested. I'm not going to post it, because
> > the code is written for my own libraries, and isn't compatible with the
> > official rds libraries. There also isn't any documentation. If there is
> > anyone interested, I can port it back for them, and whip up some docs.
> >
> >
> > Chris Bensler
> > Code is Alchemy
>
> I'm quite interested.
> I'm so tired to work on a string whose length may grow or shrink as the
> result
> of recursive processing, and code n*n times "if i>length(theString) then
> exit
> end if". If your lib causes the interpreter to behave in a coder defined
> way -
> like "on error exit" or anything akin -, then it's ok.
> Breaking compatibility is a strong decision: sometimes it must be taken,
> and
> accompanying measures must be taken alongside.
> How would you describe the performance penalty of using this? If it's
> too
> huge I'd be a bit wary, but I generally don't need cutting edge
> performance in
> my code, just reasonable one. There are fastmachines nowadays.
>
> CChris
>
>
In my experience, my exception library does not cause a performance loss
at all. The same steps are taken to throw and trap an error as is to
manually test and report an error. The difference is in the automation
of the task. Any performance penalty incurred would happen within the
error cases, by which point, perfomance is a sideline then.
I'll work on porting the lib for you.
Chris Bensler
Code is Alchemy
|
Not Categorized, Please Help
|
|
