Board index » cppbuilder » LoadPackage & EPackageError Exceptions

LoadPackage & EPackageError Exceptions


2004-07-17 02:41:12 AM
cppbuilder89
Hi all,
I'm dynamically loading packages as plugin modules for an application
I'm developing. During testing, I found that when I called the
LoadPackage() function for a package that was not present (which in
my application is likely) the function throws an EPackageError
exception when the package is not present.
I'm using BCB5 and the documentation for LoadPackage() in the Borland
Help is a grand total of 2 lines saying nothing about what happens if
the package cannot be found.
My question is for the BCB/Package guru's out there: Is this supposed
to the the standard behavior for the function, and if so, why was it
written that way? Why not have it return 0 or NULL?
I solved my problem with individual try-catch blocks around each
instance of LoadPackage() but it seems to me a little extreme to
throw the exception in the first place.
Just curious.
Drew
 
 

Re:LoadPackage & EPackageError Exceptions

Hi,
If you have PRO or above, the source file, SysUtils.pas
is on your system and you can either step into LoadPackage
(after turning ON Debug libs) or walk through the
source to see what exceptions are possible.
--Craig
 

Re:LoadPackage & EPackageError Exceptions

"Drew MacDonald" < XXXX@XXXXX.COM >wrote in message
Quote
During testing, I found that when I called the LoadPackage()
function for a package that was not present (which in my
application is likely) the function throws an EPackageError
exception when the package is not present.
Correct. It also throws an exception when the library is found but fails to
load properly.
Quote
I'm using BCB5 and the documentation for LoadPackage()
in the Borland Help is a grand total of 2 lines saying nothing
about what happens if the package cannot be found.
You have your answer - it throws an exception.
Quote
Is this supposed to the the standard behavior for the function
Yes. When you think about it, its logical - the function is throwing a VCL
style exception that its very name is specifically related to package
errors. That should be your first clue that the behavior is intentional.
Quote
and if so, why was it written that way? Why not have
it return 0 or NULL?
That is the way the VCL works. A lot of operations throw exceptions when an
error occurs.
Gambit
 

{smallsort}

Re:LoadPackage & EPackageError Exceptions

Remy Lebeau (TeamB) wrote:
Quote
>Is this supposed to the the standard behavior for the function
Yes. When you think about it, its logical - the function is throwing a VCL
style exception that its very name is specifically related to package
errors. That should be your first clue that the behavior is intentional.
Actually, I'm a C programmer originally, so I'm used to errno and return
codes. :P I always figure exceptions are for critical errors whereas
not finding the package would (in my mind) just rate an error code
to be returned.
I figured it was intentional, but I just wanted to verify it since there
wasn't anything in the documentation.
Quote
>and if so, why was it written that way? Why not have
>it return 0 or NULL?
That is the way the VCL works. A lot of operations throw exceptions when an
error occurs.
Gambit
Thanks for clearing things up for me. I appreciate it.
Cheers,
Drew.
 

Re:LoadPackage & EPackageError Exceptions

"Drew MacDonald" < XXXX@XXXXX.COM >wrote in message
Quote
Actually, I'm a C programmer originally, so I'm
used to errno and return codes. :P
Can't think that way anymore. C++ is a very different beast from C.
Quote
I always figure exceptions are for critical errors whereas
not finding the package would (in my mind) just rate an
error code to be returned.
That requires you to do per-call checking of return values. That clutters
code, and requires any errors to be prepegated up the call stack manually in
cases where failing calls are several levels deep and the higher levels need
to handle the errors. Exceptions work better in that scenerio.
Gambit
 

Re:LoadPackage & EPackageError Exceptions

Remy Lebeau (TeamB) wrote:
Quote
"Drew MacDonald" < XXXX@XXXXX.COM >wrote in message
>Actually, I'm a C programmer originally, so I'm
>used to errno and return codes. :P
Can't think that way anymore. C++ is a very different beast from C.
I know, but old habits die hard. After working with C++ for almost a
year now, I am finally, slowly, starting to appreciate some of the
differences in the language. I must say, however, that BCB is a very
nice tool for building applications. I'm not fond of the text editor,
but the VCL components and the GUI builder are fantastic.
Quote
>I always figure exceptions are for critical errors whereas
>not finding the package would (in my mind) just rate an
>error code to be returned.
That requires you to do per-call checking of return values. That clutters
code, and requires any errors to be prepegated up the call stack manually in
cases where failing calls are several levels deep and the higher levels need
to handle the errors. Exceptions work better in that scenerio.
Yeah. I guess I'm just so used to doing it the per-call way that it
doesn't seem like much of a hassle. But yes, exceptions are definitely
the way to go if you are deep into the call stack and something higher
up has to handle the errors.
Thanks again for your help.
Drew