Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
CODE PROJECT For Those Who Code
  • Home
  • Articles
  • FAQ
Community
  1. Home
  2. General Programming
  3. C#
  4. Component Exception vs Error Event??

Component Exception vs Error Event??

Scheduled Pinned Locked Moved C#
visual-studiodiscussioncsharpdelphihelp
3 Posts 3 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M Offline
    M Offline
    MilesAhead
    wrote on last edited by
    #1

    I wrote a C# component for application instance control that I'm enhancing and I wanted to get some programmer opinions. The component is designed to be dropped on the main form of the application. As a programmer using the component would you think it more convenient to have an error event or to throw an exception? Coming from Delphi I think it's convenient to create the error handler using the component property page in the IDE but I'm not sure if that's considered bad form (no pun intended) in C#? The other approach I could take would be to check if the error event is assigned and throw an exception as alternative. Any thoughts? TIA

    T G 2 Replies Last reply
    0
    • M MilesAhead

      I wrote a C# component for application instance control that I'm enhancing and I wanted to get some programmer opinions. The component is designed to be dropped on the main form of the application. As a programmer using the component would you think it more convenient to have an error event or to throw an exception? Coming from Delphi I think it's convenient to create the error handler using the component property page in the IDE but I'm not sure if that's considered bad form (no pun intended) in C#? The other approach I could take would be to check if the error event is assigned and throw an exception as alternative. Any thoughts? TIA

      T Offline
      T Offline
      TigerNinja_
      wrote on last edited by
      #2

      Have a look here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbconshouldiraiseexceptionsorreturnerrors.asp[^] I think you should follow the regular guidelines for exception handling. You might want to consider catching certain exeptions (i.e. I/O) and handling them in a more elegant way. For example, catch a FileNotFound, create a custom message and report back to the user via MessageBox. HTH

      R.Bischoff

      Denn Gott hat die Menschen so sehr geliebt, daß er seinen einzigen Sohn für sie hergab. Jeder, der an ihn glaubt, wird nicht verlorengehen, sondern das ewige Leben haben

      1 Reply Last reply
      0
      • M MilesAhead

        I wrote a C# component for application instance control that I'm enhancing and I wanted to get some programmer opinions. The component is designed to be dropped on the main form of the application. As a programmer using the component would you think it more convenient to have an error event or to throw an exception? Coming from Delphi I think it's convenient to create the error handler using the component property page in the IDE but I'm not sure if that's considered bad form (no pun intended) in C#? The other approach I could take would be to check if the error event is assigned and throw an exception as alternative. Any thoughts? TIA

        G Offline
        G Offline
        Grimolfr
        wrote on last edited by
        #3

        For controls/components or multi-threaded classes, I normally use an Error event. That way you don't get application crashes if the exception is thrown in a method running in a thread that's outside one of your parent app's try{}catch{} blocks. However, for public/internal/protected methods called directly from the parent app, I usually throw exceptions directly. This allows the developer to wrap immediate exceptions in their own try{}catch{} blocks. For a control, especially, I would only throw exceptions in constructors, properties, and public methods. Any exception thrown in a protected/private method that MIGHT be called asynchronously gets redirected to an Error event.


        Grim

        (aka Toby)

        MCDBA, MCSD, MCP+SB

        Need a Second Life?

        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • World
        • Users
        • Groups