-
Notifications
You must be signed in to change notification settings - Fork 35
Description
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.