FileMakerError adds too much abstraction

[steveWinter]

Currently if FileMaker server returns an error an exception of type FileMakerError is raised. The same exception is used for all error types.

The problem that I am finding is that I now have to parse a lengthy text string to determine what the error actually was. In many instances this wouldn't be an issues, since it's likely to be fatal to the program execution and I'd need to log the exception (for example) and then provide some generic error response.

There are however times when you want to catch a specific error and behave differently for those. Immediate use cases I'm dealing with are

• no records (401)
• validation failed (503 - 507)

Would it be possible to either raise alternative exceptions for these errors, or expose the error code in the current exception?

[davidhamann]

Currently, everything is a FileMakerError, but you can already get the error code directly from the Server.last_error property (returns an int, no need to parse text).

Example:

fms = fmrest.Server(...)
fms.login()
try:
    fms.find(query=[{'name': 'non-existing'}])
except FileMakerError:
    print(fms.last_error) # prints 401

By the way: the last script result is also always accessible through the last_script_result property.

Having separate exceptions (at least for the common cases) might be something to look into though. It probably reads nicer than the generic FileMakerError.

Maybe something like this:

try:
  fms.find(...)
except NoMatch:
  ...

We could subclass FileMakerError and thus keep it backward-compatible for existing implementations.