error handling...where to include? 
Author Message
 error handling...where to include?

-- Since error handling always searches through the call stack to find an
enabled error handler, does this mean placing error handling code in
procedures/functions that are always called by another routine a waste of
time?  If this is the case, I should only be placing error trapping code in
events/procedures/functions that call other routines...is this logic faulty?

Mitch Abaza

clear "delete" to mail



Tue, 06 Nov 2001 03:00:00 GMT
 error handling...where to include?

Although your question is simple, it is a source of much debate. You
are correct in stating that if VB does not find an error handler in the
current routine it will go back through the call stack until it finds
one. If it does not find one, the app will crash. To have a robust app,
you must include error handling in all Windows fired events at a
minimum (click events, form load, etc.). Any routines you write and
call manually is debatable.

I generally approach it this way. If the routine is likely to get an
error that it knows how to handle (file not found for example), place
the error handler right in the routine and only raise unexepected
errors back to the calling routine. If the routine is simple and does
not expect any errors (property let/get for example), don't waste your
time coding an error handler.

The best argument I have heard of why to place an error handler in
every routine is for error tracking purposes. If you trap an error in a
manually called routine you wrote, you can pass that routine name in
the err.source property back to the calling routine to be displayed or
logged. That is a big help in debugging when you get an error message
in your form and don't know which routine actually caused the error.

The bottom line is that you have to find your own style of error
handling that you are most comfortable with. I hope these comments help
you to think about the issues involved. You may also want to read the
MS books on-line and other sources regarding error handling.

Good Luck,
Doug



Quote:

> -- Since error handling always searches through the call stack to
find an
> enabled error handler, does this mean placing error handling code in
> procedures/functions that are always called by another routine a
waste of
> time?  If this is the case, I should only be placing error trapping
code in
> events/procedures/functions that call other routines...is this logic
faulty?

> Mitch Abaza

> clear "delete" to mail

--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---


Tue, 06 Nov 2001 03:00:00 GMT
 
 [ 2 post ] 

 Relevant Pages 

1. Error handling - On Error resume next

2. Error handling under SQL 6.5 and SQL 7.0, @@error doesn't work

3. OCI Error Handling (trapping UPDATE errors)

4. Strategy for handling COM errors and ADO errors

5. Error handling - Getting fully formatted error msg in SQL

6. Error of syntax in the handling of error

7. SQL-Procedure called with ODBC terminates on error and ignores TSQL-error handling

8. Error handling and custom error messages

9. error handling -- @@ERROR

10. Error handling under SQL 6.5 and SQL 7.0, @@error doesn't work

11. Custom Task Error Handling - Displaying Custom Error Message


 
Powered by phpBB® Forum Software