Exception handling with slick

[David Capwell]

New to slick, so sorry if I didn't find this, but when looking at the doc it doesn't really cover how to handle errors.  Lets say that a foreignKey check failed, I will get back a SQLException with string codes.  Does slick provide any abstraction over codes that I can use?

I am currently doing the following in the above example:

if (e.getSQLState != null && e.getSQLState.startsWith("23")) {

// return a validation issue to the user

}

I can look up all the codes myself and figure out how best to handle the different types of exceptions, but it would be nicer if there was something in slick that I could reuse.

[Christopher Vogt]

Hi David,

we currently do not support this and have no concrete plan on adding
support for this in the future. I am not sure if it is feasible at all.
And we believe other things are more important for now. This may change
if you submit a bug report for this, if other parties express a strong
interest in this as well and if a case can be made that is is feasible
to be implemented.

Chris

> --
>
> ---
> You received this message because you are subscribed to the Google
> Groups "Slick / ScalaQuery" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to scalaquery+...@googlegroups.com
> <mailto:scalaquery+...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/scalaquery/f650a587-c55d-40f3-aeaf-ba83f2eebcc0%40googlegroups.com
> <https://groups.google.com/d/msgid/scalaquery/f650a587-c55d-40f3-aeaf-ba83f2eebcc0%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Erik Post]

Hi David,

I think it would be even nicer to have a library for this *independent* of Slick. After all, there's nothing Slick-specific about it. For a quick sketch, see https://gist.github.com/epost/7dae15b918c5e244412c. This way, it would be easy to reuse between different db libraries. 

Cheers,

Erik

[Christopher Vogt]

Great idea! Maybe you guys can create one.

Chris

> --
>
> ---
> You received this message because you are subscribed to the Google
> Groups "Slick / ScalaQuery" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to scalaquery+...@googlegroups.com
> <mailto:scalaquery+...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/scalaquery/db6ccdf2-9d89-43a4-994a-72eeed4c2f1d%40googlegroups.com
> <https://groups.google.com/d/msgid/scalaquery/db6ccdf2-9d89-43a4-994a-72eeed4c2f1d%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Erik Post]

Hi,

As a follow-up, it seems tpolecat has been doing some work on this for Doobie, his pure JDBC library:

https://github.com/tpolecat/doobie/blob/master/core/src/main/scala/doobie/dbc/sqlstate/PostgreSqlState.scala

Perhaps it would be worthwhile to externalize some of that stuff. I might get to this in a while, as my SQL error processing needs reach critical mass.

Cheers,

Erik

> <mailto:scalaquery+unsub...@googlegroups.com>.

[Christopher Vogt]

> As a follow-up, it seems tpolecat has been doing some work on this for
> Doobie, his pure JDBC library:
>
> https://github.com/tpolecat/doobie/blob/master/core/src/main/scala/doobie/dbc/sqlstate/PostgreSqlState.scala

We have a ticket to check out doobie and see how it relates or
integrates with Slick: https://github.com/slick/slick/issues/851

> Perhaps it would be worthwhile to externalize some of that stuff.

Quite likely!

> I
> might get to this in a while, as my SQL error processing needs reach
> critical mass.

Please do. Looking forward to a PR! As we use Exceptions, it may make
sense to just optionally provide the status in the SlickException.

Chris