Npgsql exception when connecting

Question

I am using the Npgsql 2.0.11.94 in a C# .NET 4.0 application to connect to a PostgreSql database. I have formed the connection string according to the example on their website, and when I call connect with the NpgsqlConnection object, this exception is thrown:

A first chance exception of type 'Npgsql.NpgsqlException' occurred in Npgsql.dll

Additional information: ERROR: 22023: 3 is outside the valid range for parameter "extra_float_digits" (-15 .. 2)

The code will execute correctly after the exception is thrown. That is, the connection to the database does get established and the queries return the correct data. Does anyone know why it's throwing this exception? Here is my code to connect to the db:

string strConnection = "Server=192.168.253.20;Port=5432;User Id=alex;Password=asdf;Database=mydatabase;";
NpgsqlConnection conn = null;
try
{
    conn = new NpgsqlConnection(strConnection);
    conn.Open();
}
catch (Exception e)
{
}

Any help would be much appreciated.

Thanks, Alex

Answer 1

Jon Hanna correctly explains why we have such a try-catch and why the exception is being thrown. The issue is VS.net will show you any exception which is thrown, even those which are eaten by a try-catch exception handling like Npgsql is doing.

I think vs.net behaves like that, correctly, to show you that there are still exceptions being thrown although they are being handled, and in this specific case, simply ignored.

You can check that this exception only appears when you are debugging your code with vs.net. Also, as you also noticed, your code continues to work as if nothing wrong happened. So, you don't need to worry about that.

I hope it helps.

Answer 2

It's a bug with the initial set-up upon establishing a connection.

There are a few different commands that get carried out on every connection that is first opened (but not repeatedly when pooled connections are re-used), and this one is at attempt to deal with the different degrees of precision allowed with floating-number formatting between different versions of PostgreSQL.

Clearly it's not going quite as planned.

Taking a quick look at the source, it seems that the call is wrapped and should eat any such exception, but maybe that's after the last release. If so, then building from source may solve your problem.

Or you could go back a version, or just wrap with a try-catch until the next release.