Commented by: GR (gr)

Unfortunatelly, there is no opportunity to "vote against" here.

Personally I'm absolutely sure that this is awfull suggestion; firebird.log shouldn't contain any new "logic-level" errors, warnings and messages, but system-level errors only.

It should be nice, if db-level trigger (and other similar) errors logged somehow/somewhere, but not in the firebird.log.

Commented by: Arioch (arioch)

i'd add dumping current_user, current_connection and perhaps some more variables that may affect the trigger's behavior into the log.

if person does not want log pollution, he can
1) avoid creating on-disconnect trigger
2) wrap the trigger body into explicit exception catcher. If developer wants to ignore and suppress all the errors - just do it explicitly.

> nice, if db-level trigger (and other similar) errors logged somehow/somewhere

Yes, per-database log might be good. But there is no such thing now.
Since you mentioned "other similar" - then you probably consider server log alreayd polluted.

Then the solution is introduce new separate log file, not to disable error logging.

Post new ticket for creating per-database log or whatever, if you think that is required.

Commented by: GR (gr)

> if person does not want log pollution, he can
> 1) avoid creating on-disconnect trigger

Sure. Then use this way yourself - don't create db-triggers.

> 2) wrap the trigger body into explicit exception catcher. If developer wants to ignore and suppress all the errors - just do it explicitly.

Again - why don't you log errors explicitly - anywhere you want?

> Yes, per-database log might be good. But there is no such thing now.

It may be planned for 3,0, DB-level config already planned, so
db-level logs will be logical continuation.

> Since you mentioned "other similar" - then you probably consider server log alreayd polluted.

I'm not sure, because i don't know full list of errors. And study
English grammar, please - it was "conditional" clause.

> Post new ticket for creating per-database log or whatever, if you think that is required.

Let see what will be done with current ticket, don't rush.

Commented by: @asfernandes

I'm more on the "you need it logged, then log it". Current behavior is well documented.

Trace is the correct way to check for general errors, IMO.

Commented by: @aafemt

Guys, have you ever heard word "bug"? Have you ever wrote a code that contained one? How had you found this bug if it didn't cause any error message appear anywhere?..

Commented by: GR (gr)

Why anywhere? Why just don't handle this "bug" at the place?

And at last, why this is a bug? This is application-level error (business exception), isn't ?

Commented by: Sean Leyne (seanleyne)

@dimitry,

Are you saying that the Firebird Log should contain these error?

Or, are you saying that FBTrace is the right tool to handle this?

Commented by: @ibaseru

GR, trigger errors goes to client application. On Disconnect trigger errors goes nowhere. To understand are there errors or not, you need to
- log them
or
- wait for them using trace api.

for example, will you wait in trace for several days to catch such an error? I think no.

Commented by: Sean Leyne (seanleyne)

KDV,

I think that it is "streching" things to say that it would take "several days" to catch the errors.

Commented by: GR (gr)

KDV,

> for example, will you wait in trace for several days to catch such an error? I think no.

No, I will not write such triggers without exception-handling, if it is needed.

Current situation is easy - no triggers by default - no errors - no problems.
If someone changes it (creates a trigger) - handle errors as usual.

User (application-side) errors - user handling, server (net, engine) errors -
server handling to the firebird.log. I think, it is quite fair. And you ?

Commented by: Arioch (arioch)

> Sure. Then use this way yourself - don't create db-triggers.

Nice idea. How can i make server reliably execute some code when the connection suddenly goes off or application crashes w/o using on-disconnect or on-rollback triggers ?

> Why just don't handle this "bug" at the place?

Because to handle the bug one should be aware of it. You ask to conceal the bug and make developers oblivious to its existence. Then you ask developers "why didn't you fixed the bug that i didn't wanted you to know about"

If you are sure you would write those triggers error-free, then why bother ? Your log would be pristine no matter what the outcome of this ticket would be.

> This is application-level error (business exception), isn't ?
Only in 3-tier structure, when clients do not have direct access to RDBMS.

In C/S mode those triggers can be fired by many conditions including conditions not related to applications. More so - that is their main reason d'etre. If application goes as normal i can make any clean-up in TDatabase.BeforeDisconnect event or like. Those triggers are server-side safety net warranting that cleanup would happen even when application or connection is defunct. Idea to report to application errors about unavailability of that application is but catch 22.

> why don't you log errors explicitly - anywhere you want?
1) Because PSQL doesn't fit for general logging.
2) Because those are exceptions, not special return values. When programming with retvals it is natural and expected to check every statement for error explicitly. When programming with exception it is natural to flow the statements and separate error interceptions. It is not natural to wrap every trigger into exceptions catcher/logger. The question is what would be the sink for uncaught exception. It cannot be user application, since those triggers are designed to fire when the very existence of that application is no more given.

Commented by: GR (gr)

> Because to handle the bug one should be aware of it.

If some triggers can contain errors and this is important for you - yes, you should be aware of it.

> > This is application-level error (business exception), isn't ?
> Only in 3-tier structure, when clients do not have direct access to RDBMS.

Seems, we have different interpretation of application/server levels...

> 1) Because PSQL doesn't fit for general logging.

Have you ever log the errors ?

> It is not natural to wrap every trigger into exceptions catcher/logger.

Don't log exceptions in all triggers, but in disconnect/rollback only.