Zeoslib Portal

Hello,

I was going through the source code to raise EZUnsupportedExceptions where necessary and did a quick search.
" Raise Exception.Create"
appears at 101 places inside Zeos, and raising the base Exception object directly is never a good idea.

What do you think if we replace all normal exceptions with EZSQLException?

Would fit the suite a little bit better I think.

I fully agree

After the replacement, the following units had to import ZDbcIntFs as they had no idea what EZSQLException is:
- ZSysUtils (Core)
- ZClasses (Core)
- ZPlainLoader (Plain)
- ZVariables (Core)
- ZDbcProxyUtils (DBC, this is fine)
- ZScriptParser (ParseSQL)

If I make the checkin like this, Core, Plain and ParseSQL will reach to an upper package (Dbc), which is also not ideal.

The definition of EZSQLThrowable and EZSQLException have to me moved back to Core if we want to keep the structuring. Keep in mind that EZSQLThrowable can be inherited from EDatabaseError, maybe this is why it's at DBC?
Thoughts about this? Go / no-go? Any particular "base" typedef unit I can use or just create a new one (ZExceptions)?

Well - this touches a problem where Egonhugeist and me disagree - a lot. I think that Zeos exceptions should be implemented in ZCore and that they should inherit from EDatabaseError. Egonhugeist thinks that Exceptions should not derive from EDatabaseError because some people seem to think that pulling the DB unit into their programs gives them bad Karma or something like that. I never understood this. Sorry if this part of the post contains sarcasm. I can't help it.

Soooo - what to say - from my POV we should move these exceptions and use them. People already are able to decide if they want to derive from EDatabaseError or not. Exceptions should be declared in core units, so they can be used consistently throughout all Zeos code.

In this case I'll simply move exception definitions in a separate unit under Core.

I too do believe that that is their place.

I hope no manual work is involved when patches are applied... about 80 files had to be changed :)

Fresh and crispy pull request available on GitHub.
I also added the missing Xml reference to DBC as it made my command line compilation to fail.

Let's see what Jenkins will say.

Applied

Damn, the test suite... it was in my mind to doublecheck the uses clauses in them too but then the package didn't want to compile and while I was fixing that I forgot about it...

Thanks for fixing them up!