- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
// Allow the default global exception handler to handle all errors
throw new fristException("Frist comment is always suspect")
Admin
SEH - Structured Exception Handling is the native exception handling mechanism for Windows and a forerunner technology to Vectored Exception Handling (VEH). It is NOT C++ (or Java or .NET or similar), but something in its own right [and usually disabled these days]
Admin
Properly speaking, "structured exception handling" is specific to 32- and 64-bit Windows systems, and has little or nothing to do with programming-language exceptions. (Most of the events that trigger SEH exceptions are what we'd normally think of in a UNIX system as signals such as SIGSEGV, SIGBUS, SIGILL, and so on, but also e.g. trying to close an invalid handle.)
Admin
It's like playing Diablo 2 in hard core mode. One network lag and your level 90 character is dead!!
Admin
Sounds like someone is looking forward to Thursday...
At least the expectation is explicitly stated...
Admin
So... the data handling API bubbles exception to API clients. When it has a legitimate exception, what alternative is there? Just pretend the data action succeeded and return no data back to the client? Return "false"?
The general idea of bubbling the error up is sound. It has some implementation details that need to be discussed; such as "what if the client is javascript and our exception classes aren't terribly useful?". Also, if the clients aren't all internal, then we need to be concerned about how much detail is presented to them.
None of those consideration will cause us to abandon the current course. The fix is probably as simple as adding a global error handler that makes the error easily consumable in the client technology, and probably logging all of the exception detail and providing a reference number so support can help a client with an issue (or for internal use, the client developer can go look it up themselves).
Admin
In my view there are two reasons to catch an exception.
You can do something intelligent about it. That might mean write something in a log, or the query failed so try to create a new database connection and do it again, or roll back a transaction to return everything to a known valid state, call cleanup() , etc.
Because you specifically want to control what information is allowed to propagate back up the stack. In these cases you will usually re-raise. You might add some additional context for sake of a higher layer doing better logging or perhaps you want to remove some details, a network service might not want to give clients specifics about what went wrong at the database layer, which might produce its only completely adequate logs already, and you don't want some un-trusted client knowing they selected a duplicate key, its enough to tell them - "the requested action could not be completed".
In other cases you should resist the urge to litter your code with gratuitous try, catch, except, structures. I have worked with way to many people that think just because something they are calling can throw/raise the need to have try structure around it right then and there. They accomplish little other than making the control flow a lot more difficult to understand, or worse they accidentally mask/swallow the exception by failing to re-raise, 'on error resume next' is very rarely a good idea, better to die/abend sooner in 99% of cases then plow ahead most of them.
Admin
Honestly, I'd be okay with this for most library code. It's not ideal — a well-designed library that catches and re-throws meaningful exceptions would be better — but it's a huge improvement over "catch and swallow", or "catch and throw generic exception with no context".
Admin
The same people who don't know VBA's "Option Explicit" do know "On Error Resume Next".
Admin
Exactly this - almost all exception handling I have seen in code is superfluous. For a web server, the appropriate response is usually to abort processing of that request but continue processing other requests and, surprise, surprise, most web servers do this by default. Similarly for a UI (whether javascript or thick client) most frameworks will abort processing of the current UI event but carry on processing others.