ArangoServerException eats up all the useful information like status code and error number

[isen-ng]

public ArangoServerException(BaseResult baseResult)
      : base(string.Format("{0}. ErrorNumber: {1} HttpStatusCode: {2}", (object) baseResult.ErrorMessage, (object) baseResult.ErrorNum, (object) baseResult.Code))
    {
    }

This line flattens the useful information into a string and essentially throws them away. Useful information should have been preserved as properties in the exception so that user can update his or her program flow based on the error type.

Eg, if the user wanted to create his/her own upsert collection method. That requires the user to test if the collection exists by either getting the collection information, or try creating the collection. Both of which throws exceptions and the user needs to handle them accordingly. But because the user could not get the specific status code and error number, the user does not know how to differentiate a regular ArangoServerException.

There is a workaround: this setting can be set to false, and the user can handle the errors in the BaseResult.

db.Setting.ThrowForServerErrors  = false

Although the workaround works, ArangoServerException should still contain the error details so that user's don't have dig so deep to find this workaround.

I can send a PR if you need it.

[isen-ng]

In the case of db.Document<T>(string key), this method does not even return a BaseResult and thus all useful information is lost when the information is flattened in the exception.

[ra0o0f]

@isen-ng sorry for the late response, you are right BaseResult could be member of ArangoServerException so users can decide what to do next base on the error