arangodb-php

arangodb-php copied to clipboard

This is how it looks in symfony when the driver throws an exception - not really self-explaining without the additional information available via getDetails. I was wondering if there is a reason why the details are not in $e->getMessage().

Why does it bother me? For Symfony I have to implement a custom error handling thing to access getDetails() on application level, this is something I don't want to do just for one library in my stack. Am I getting the concept wrong?

I originally coded it like this to let the user decide if the full exception message is needed or not.

If that's more work, I don't mind if we always put the full message into what's returned by getMessage()

Yes, why not.. let's do it..

BTW. In the new core I am passing through almost everything and let the higher level library handle this kind of stuff(exceptions etc...)..

I have another question on the exceptions: while I played around with the driver for my symfony demo I realized that it throws exceptions where I did not expect them, e.g. if you try to delete an document which does not exist any more. There are lots of use cases when the app tries to delete a document e.g. twice triggered by user behavior (e.g. two tabs, double clicking). For my taste it should not throw an exception but return false in this case.

I am afraid that is a long discussion... I am not really sure what the best is, todo in those situations. You can always use try...catch as the exceptions will bubble up

In the core driver I've been returning the actual payload from the server. Exceptions until now are only thrown in really hard cases, like connection errors. Though I must dive into that when I have finished all the rest of the groundwork...

In my opinion the higher level driver should then decide what to do with that response.

I'll be working on that a bit, today.

Your approach for the new core driver sounds fine to me. In my opinion the driver should throw exceptions in case you are doing something wrong, which can never work, e.g. have a syntax error in your AQL, try to create duplicate collections. And if the system itself is not operating at all, of course ("no connection").

And: I don't like cluttering my code with too many try..catch statements for several reasons:

• it makes the code more difficult to read
• I have to implement exception related infrastructure only once (on application level), e.g. logging the error, implementing some special stuff if the request was an Ajax request

That's why I like the new approach :-)