Hi, Alexander How about adding a "fatal event" to the connection object? Most probably passing the connection itself and an exception struct of some sort, allowing the handler to suppress rethrowing of the exepctions? I`ve seen this done by MS in gridviews and so on and it seems handy - if the handler decides it can recover - it simply suppresses the exception, if not ... bad things happen :) Actually, total suppresion is probably not a good idea, and something should be thrown (to notify the possible executing query of the problem), but it could be less severe.
Don`t know if it sounds like a good idea, but I thought it`s worth sharing Ivan > Hi Jiri > > I would like to make a seperation between recoverable exceptions and > fatal > exceptions coming from the database. > > A fatal error might be network lost, database gone, ... If this happens > I > would like to try to "reconnect" the client or even shutdown the > application. > > A recoverable error, might be an exception, a FK violation or whatever. > This would result in me just notifying the user what went wrong. > > Yesterday I tried looking for FbExceptions that where raised on > Application > level, but this was insufficient. Sometimes I had another exception > raised > by the provider and I would even like to catch those. > > Do you have any idea on how to solve this? > > Thanks > > Alexander > > > ------------------------------------------------------------------------------ > _______________________________________________ > Firebird-net-provider mailing list > Firebird-net-provider@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/firebird-net-provider -- Sanity is a sin! ------------------------------------------------------------------------------ _______________________________________________ Firebird-net-provider mailing list Firebird-net-provider@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
