• Indifferent (unregistered)

    On Error Raise Frist

  • r (unregistered)

    ON ERROR DROP COMMENT

  • MightyM (unregistered)

    That programmer should take a look at Vigil. It delivers that functionality out of the box.

  • JA (unregistered)

    Cheesoid kill self.

  • (cs) in reply to MightyM
    MightyM:
    That programmer should take a look at Vigil. It delivers that functionality out of the box.
    And if I don't handle an exception that you throw, Vigil deletes your code, not mine.

    Well, OK, on the next run it deletes my code because I am calling a function that doesn't exist, but it deleted your code first, triggered by my bug.

    Vigil's "swear" and "implore" are merely synonyms for a somewhat harsh version of assert, as I'm sure you're all aware.

  • Nahkh (unregistered) in reply to Steve The Cynic

    You clearly lack the conviction to cope with morally pure code.

  • (cs)

    If code fails it is right and proper that it commits Seppuku

  • (cs)

    I don't really see a huge problem considering what it's apparently used for. It looks like an automated audit log. What should you do when logging fails? Log it somewhere else instead? How would you consolidate that back into your database properly, especially since a select is required to get the proper data in the first place?

    Throwing an error back to the user would also not make sense. Why would you throw an error to the user if the changes they made worked perfectly but you failed to log the fact that they changed things?

    Of course a better way to do this would be to handle the audit log in your framework where any query is automatically logged (and in which you can send a message to support if something goes wrong), but lacking that I don't think this is that terrible of a solution.

  • Rorre (unregistered)

    Fortunately, in most cases the Catch will fail since in a proper system the calling user won't have permission to drop triggers.

    One would hope.

  • (cs) in reply to NMe
    NMe:
    I don't really see a huge problem considering what it's apparently used for. It looks like an automated audit log. What should you do when logging fails? Log it somewhere else instead? How would you consolidate that back into your database properly, especially since a select is required to get the proper data in the first place?

    Throwing an error back to the user would also not make sense. Why would you throw an error to the user if the changes they made worked perfectly but you failed to log the fact that they changed things?

    Of course a better way to do this would be to handle the audit log in your framework where any query is automatically logged (and in which you can send a message to support if something goes wrong), but lacking that I don't think this is that terrible of a solution.

    Your proposal is that the framework could contain no ability to log or neatly customise logging output. If so, I would assert that it indicates another WTF, and one way or another indicates a WTF.

  • (cs)

    That's where Oracle clearly beats this amateuristic DB. Whenever you do as much as thinking about a command that vaguely looks like a CREATE, ALTER, or DROP, all triggers are immediately deactivated. Much better.

  • faoileag (unregistered)

    "If at first you don't succeed, destroy all evidence that you tried." - Steven Wright

  • (cs) in reply to NMe
    NMe:
    Throwing an error back to the user would also not make sense. Why would you throw an error to the user if the changes they made worked perfectly but you failed to log the fact that they changed things?
    I think you may have overlooked the
    ROLLBACK TRANSACTION
    in the catch block. The user's changes haven't been made at all, but detecting that and informing the user of it is left to the next layer up. I would rather receive an error telling me that the software is buggy than have it silently ignore my input.
  • nobulate (unregistered)

    This is a corollary in practice: The less code you have, the less bugs you have.

    This design pattern embodies self-adjusting code that improves the performance and stability of your system over time!

    The event horizon to the birth of SKYNET is nearing ever closer...

  • erm (unregistered) in reply to NMe
    NMe:
    I don't really see a huge problem considering what it's apparently used for. It looks like an automated audit log. What should you do when logging fails? Log it somewhere else instead? How would you consolidate that back into your database properly, especially since a select is required to get the proper data in the first place?

    Throwing an error back to the user would also not make sense. Why would you throw an error to the user if the changes they made worked perfectly but you failed to log the fact that they changed things?

    Of course a better way to do this would be to handle the audit log in your framework where any query is automatically logged (and in which you can send a message to support if something goes wrong), but lacking that I don't think this is that terrible of a solution.

    No. Just no.

  • QJo (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    MightyM:
    That programmer should take a look at Vigil. It delivers that functionality out of the box.
    And if I don't handle an exception that you throw, Vigil deletes your code, not mine.

    Well, OK, on the next run it deletes my code because I am calling a function that doesn't exist, but it deleted your code first, triggered by my bug.

    Vigil's "swear" and "implore" are merely synonyms for a somewhat harsh version of assert, as I'm sure you're all aware.

    The real joke is that the example code is a function called "fib". Perhaps this language could be used to write a program to process Lie groups?

  • Smug Unix User (unregistered)

    Coding with Permadeath? I see this as the next big thing.

  • faoileag (unregistered) in reply to NMe
    NMe:
    I don't really see a huge problem considering what it's apparently used for. It looks like an automated audit log. What should you do when logging fails? Log it somewhere else instead? How would you consolidate that back into your database properly, especially since a select is required to get the proper data in the first place?

    Throwing an error back to the user would also not make sense. Why would you throw an error to the user if the changes they made worked perfectly but you failed to log the fact that they changed things?

    If you can't see what's wrong with a logging mechanism that silently removes itself the first time an error occurs and doesn't even report the fact, then that's a wtf in its own right.

    That code contains two very serious wtfs:

    1. if that trigger runs into an error then the whole transaction is rolled back. Silently, as it seems. No, not just the audit logging, everything since the last BEGIN TRANSACTION. If that goes undetected by the application, than you are in an inconsistend state between application and database and that is plain wrong.

    2. if the trigger runs into an error it removes itself. If you rely on audit.Account to provide information on changes someone made to his or her account and that trigger is silently removed, than after that your database is basically corrupted, since audit.Account does no longer reflect the changes made.

    In a scenario where legal requirements exist to provide a backtrace of a users activity, this sort of error handling can get you neck deep into <insert_material_of_choice>.

  • ANON (unregistered)

    Very lazy. It should at least drop the database, else the data might be corrupted.

  • Valued Service (unregistered)

    If this is propagated everywhere, even in non-triggers, would this create a cascade delete of all sproc?

  • Valued Service (unregistered) in reply to Smug Unix User
    Smug Unix User:
    Coding with Permadeath? I see this as the next big thing.

    We made the next gen consoles with Diablo 4 in mind. It supports hard-core consoling by default. If they fail to satisfy when performing a function, that functionality is deleted. If they fail too often, they brick.

  • Krunt (unregistered) in reply to NMe
    NMe:
    I don't really see a huge problem considering what it's apparently used for. It looks like an automated audit log. What should you do when logging fails? Log it somewhere else instead? How would you consolidate that back into your database properly, especially since a select is required to get the proper data in the first place?

    Throwing an error back to the user would also not make sense. Why would you throw an error to the user if the changes they made worked perfectly but you failed to log the fact that they changed things?

    Of course a better way to do this would be to handle the audit log in your framework where any query is automatically logged (and in which you can send a message to support if something goes wrong), but lacking that I don't think this is that terrible of a solution.

    On the slim chance that you may be serious and not trolling, allow me to correct you.

    Including DDL in an audit trigger that drops itself if it fails is utterly moronic. Just because the software fails to log something doesn't mean it should arbitrarily commit suicide.

    Also, failing with an error message when auditing fails is perfectly legitimate and reasonable depending on the application. If audit logging is an important security requirement, you do NOT want the application to continue running silently without it - you want it shouting about the failure and in some instances refusing to continue until it's re-enabled.

    The key is in the name - audit log. When you need to actually produce an audit report and find there's no data in there, you would be a little perturbed.

    Also DDL inside a trigger is just.. no. Wow. No. Never.

    This is the very definition of a terrible solution.

  • Krunt (unregistered) in reply to Rorre
    Rorre:
    Fortunately, in most cases the Catch will fail since in a proper system the calling user won't have permission to drop triggers.

    One would hope.

    ROFL.

    I commend you for your optimism, sir.

  • Rick (unregistered)

    This looks like T-SQL on SQL Server. I don't have a SQL Server instance handy, but if I recall correctly trying to drop an object while it was executing would just throw an error.

    For example on Sybase (which used to share a code-base with SQL Server, and which also uses T-SQL), a procedure which tries to drop itself will yield the error:

    Could not execute the statement. Cannot drop the procedure 'TestDropProc' because it is currently in use. Sybase error code=3702 Severity Level=16, State=1, Transaction State=0 Line 5

  • belzebub (unregistered)

    Thats just a standard samurai code - in case of an error, the only honorable think to do is to commit seppuku.

  • belzebub (unregistered) in reply to belzebub
    belzebub:
    Thats just a standard samurai code - in case of an error, the only honorable think to do is to commit seppuku.
    No, no! I meant "thing"!!! ..too late .. aagghhhh.. kkchhrrrr..... eeaaghhhh.. eee...eeeeeeeeeegghh.. ugh.. ..ah
  • faoileag (unregistered) in reply to belzebub
    belzebub:
    belzebub:
    Thats just a standard samurai code - in case of an error, the only honorable think to do is to commit seppuku.
    No, no! I meant "thing"!!! ..too late .. aagghhhh.. kkchhrrrr..... eeaaghhhh.. eee...eeeeeeeeeegghh.. ugh.. ..ah
    Ah come on... it's just a typo and there's only two keys between the "k" and the "g".

    The top bit of your left pinky should be sufficient.

  • Volvx (unregistered)

    Forget self-modifying code, meet self-destructive code.

  • Anon (unregistered) in reply to JA
    JA:
    Cheesoid kill self.

    That's not petrol, Cheesoid!

  • anonymous (unregistered)

    Can anyone deconstruct what it's attempting to do BEFORE it commits seppuku if it fails?

    WHEN (SELECT COUNT(1) FROM deleted) = 0
    THEN N'i'   -- the Knights Who Say N'i' were here
  • PC Amok (unregistered)

    I support this self-destruct pattern and would encourage many, many of my colleagues to implement it in their code if possible.

    CAPTCHA: iusto give a damn.

  • gtg (unregistered)

    Version control your database schema.

    That is all.

  • Anonymous') OR 1=1 (unregistered)

    It's like FuckItJS for databases.

  • Lealcy (unregistered) in reply to Volvx

    Cut the member who dishonor you.

  • Valued Service (unregistered)

    This code pattern might actually save IE, or... Windows even!!!

  • (cs) in reply to MightyM
    MightyM:
    That programmer should take a look at Vigil. It delivers that functionality out of the box.
    Vigil:
    Eternal moral vigilance is no laughing matter.
    It was me all along!
  • BillClintonsWeiner (unregistered) in reply to Roby McAndrew
    Roby McAndrew:
    If code fails it is right and proper that it commits Seppuku

    This pattern will be known henceforth as "Seppucode"

  • (cs) in reply to BillClintonsWeiner
    BillClintonsWeiner:
    Roby McAndrew:
    If code fails it is right and proper that it commits Seppuku

    This pattern will be known henceforth as "Seppucode"

    +1 - Seppucute!

  • (cs)

    I prefer code which deletes itself upon success . See, e.g. "trap door" and other cool ways to wreck a perfectly good Vacation Destination Featuring Dinosaurs. The original book, not the movie.

  • anonymous (unregistered) in reply to cellocgw
    cellocgw:
    I prefer code which deletes itself upon *success* . See, e.g. "trap door" and other cool ways to wreck a perfectly good Vacation Destination Featuring Dinosaurs. The original book, not the movie.
    That's even better... if at first it does not succeed, it lurks until it might try again and wreak all nature of unexpected havoc.
  • On Error Delete All (unregistered)

    If at first you don't succeed, destroy all evidence that you tried

  • anonymous (unregistered) in reply to BillClintonsWeiner
    BillClintonsWeiner:
    Roby McAndrew:
    If code fails it is right and proper that it commits Seppuku

    This pattern will be known henceforth as "Seppucode"

    +MAX_INT

  • Ted Cod (unregistered) in reply to Krunt

    Also using a DB that allows you to put DDL inside a trigger is just no. Wow. No. Never.

    This is the very definition of a terrible database.

    Seeing as if it's allowed lots of people will do it, no matter how stupid 'it' is.

  • Rob (unregistered) in reply to Indifferent

    On Error Raise Fist

  • (cs)

    I can not see single use for the DROP Trigger. Also will DB allow you to delete an object from itself?

  • (cs)

    TRWTF is that the calling object probably never began a transaction, so this exists only because the ROLLBACK TRANSACTION fails and the DROP TRIGGER never executes.

  • (cs)

    On error raze trigger.

  • (cs)

    Kinda falls into the category of:

    "Make love not war".

  • mara (unregistered) in reply to herby
    herby:
    Kinda falls into the category of:

    "Make love not war".

    Because the author was apparently f&*#$d in the head?

  • (cs) in reply to Loose Bree
    Loose Bree:
    On error raze trigger.
    +1

Leave a comment on “Dropped Catch”

Log In or post as a guest

Replying to comment #:

« Return to Article