Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hooks on errors #3

Open
cbandy opened this issue Apr 7, 2015 · 5 comments
Open

Hooks on errors #3

cbandy opened this issue Apr 7, 2015 · 5 comments

Comments

@cbandy
Copy link

cbandy commented Apr 7, 2015

Is there a particular reason hooks are not called when the underlying driver returns an error?

I can't quite think of a use case for statistics, but I can imagine logging all database interactions.

@cgilling
Copy link
Owner

cgilling commented Apr 7, 2015

Hmmm thats a good point. I can see that being useful to be able to get that information.

So the question is how much context would we want around these errors? We could have a generic error callback for all errors that occur? Or we would want an error callback for connections, statements, transactions, queries, and execs all separately.

@cbandy
Copy link
Author

cbandy commented Apr 10, 2015

I think we would want the highest resolution possible at the core. Other wrappers could aggregate or filter as desired.

My initial thought was that each hook take an error argument, but the names don't sound quite right. For example when Open returns an error, no "Conn [was] Opened."

@cgilling
Copy link
Owner

Sorry been really busy lately.

Having more granularity at the core does seem like the way to go. I was considering having a separate ErrorHook interface that could optionally be implemented by a hook have error calls corresponding to the various Hook calls.

I do like the suggestion of having it just be part of the various Hook calls already in place but it does bring in the little bit of strangeness that you are talking about. I think I might be able to live with that if it gives an easy way to return the errors when they occur.

Any thoughts about having a second ErrorHook interface?

Also I'm wondering about if we want to do anything special to handle ErrBadConn or just leave that up to the various implementors. I'm assuming most of the time those would want to be handled separately from other errors because its not so much something wrong with the Query or Transaction, but some network problem or timeout or something on the server side of things.

@cbandy
Copy link
Author

cbandy commented Apr 22, 2015

I was considering having a separate ErrorHook interface that could optionally be implemented by a hook have error calls corresponding to the various Hook calls.

Another interface sounds reasonable. Rather than "optionally implemented," there would need to be another Add method and another list, I think.

Also I'm wondering about if we want to do anything special to handle ErrBadConn or just leave that up to the various implementors.

I don't have any thoughts on this at the moment.

@cgilling
Copy link
Owner

I implemented my proposed change for this in #4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants