|
RugbyLeague wrote: Discarding errors is a great way to give the user the perception that all is right with the world.
Old VB6 provided a more convenient means, though: "ON ERROR RESUME NEXT". Unfortunately, its lack of "Try"-style methods for many things(*) tended to make a more appropriate coding style painful.
(*) There are many places where one might want to do an operation which one expects might fail, and not worry if it does; e.g. one may want to create a table if it doesn't exist, but ignore it if it does. Checking for existence before creation won't completely solve the problem, since another client might create the table after the existence check. The nicest way would be to say "do command X, but don't worry if it fails." Unfortunately, the only convenient way to do that is with ON ERROR RESUME NEXT, a concept so ugly Microsoft defined a special statement just for it.
Incidentally, if a routine does an ON ERROR RESUME NEXT and then invokes another routine that fails but does not have an ON ERROR statement, that other routine will exit out to the routine which did the ON ERROR RESUME NEXT. Nasty, but not so horrible as ON ERROR RESUME, which would restart the entire statement in the parent routine, likely causing many statements in the called routine to be re-executed.
|
|
|
|
|
RugbyLeague wrote: a great way to give the user the perception that all is right with the world.
That's the goal, according to some of the teachers here.
If you find yourself in such a group, by all means, adapt or leave - you'll be the source of all bugs and errors if you try to move to structured error-handling
I are Troll
|
|
|
|
|
Eddy Vluggen wrote: you'll be the source of all bugs and errors if you try to move to structured error-handling Smile
Fair point.
Steve
|
|
|
|
|
Eddy Vluggen wrote: you'll be the source of all bugs and errors if you try to move to structured error-handling
so right^^ once turning on printing error messages to stderr, there was so much outpu - it was turned off immediately
|
|
|
|
|
Kevin Drzycimski wrote: directly after the head opens a try block over the whole body. all errors are just thrown away.
In Enterprise lingo, that's called the Try/Swallow pattern.
Jon Sagara
Some see the glass as half-empty, some see the glass as half-full. I see the glass as too big.
-- George Carlin
.NET Blog | Personal Blog | Articles
|
|
|
|
|
Jon Sagara wrote: Try/Swallow
I'm scared to reply to that one!
DaveIf this helped, please vote & accept answer!
Binging is like googling, it just feels dirtier.
Please take your VB.NET out of our nice case sensitive forum.(Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
|
|
|
|
|
DaveyM69 wrote: Jon Sagara wrote:
Try/Swallow
I'm scared to reply to that one!
Dave
Promise, it won't swallow you, Dave.
|
|
|
|
|
So, did they patent this? o_O
|
|
|
|
|
dont know, but I had to laugh so hard when he told me this...
everybody who knows the disciplines of "Software Engineering" must either laugh or puke
|
|
|
|
|
It's from BP's oil valve device driver source code..
|
|
|
|
|
Haha, funny. Sadly enough, I used to swallow exceptions in code as well. However, I'm not in the professional field, just personal. It worries me that this sort of thing is done by professionally employed developers. xD
|
|
|
|
|
|
I think the point was that it was in EVERY method ...
|
|
|
|
|
Apparently you are not a man of faith, and do not realize that this is a Marine software design tactic. Swallow 'em all and let God sort 'em out!
Honestly Illustrated
<Pretentious> Raid tha manyuhl. :E
<Pretentious> Aw raid eh own mah meaxbile. :E
|
|
|
|
|
I'm guessing that the convention dates from the VB style, used to use this:
Function Wibble() As String
Dim sResult As String
On Local Error GoTo Fail
'stuff goes here
done:
Wibble = sResult
Exit Function
Fail:
LogError "Wibble", Err
Resume done
End Function
Panic, Chaos, Destruction.
My work here is done.
or "Drink. Get drunk. Fall over." - P O'H
|
|
|
|
|
well, the difference is, that your code logs the error.
in try/swallow it just thrown away.
logging all the error messages might bloat the logfile
|
|
|
|
|
If you have common functions reachable by the GUI, that are not important for the main of the application, this is a really usefull and stable act, and i do it in almost the same manner for at least the common methods.
For example i wan't to change a image of a specified object. Now my ChangeImage() method throws a unhandled exception, with this try catch block around the method body there will be no quaint exception message, the application won't crash because of a single method exception, only the ChangeImage() method isn't working.
Sorry for my bad english.
|
|
|
|
|
|
_beauw_ wrote: Even logging these failures in a production environment can impact other critical systems.
..logging doesn't require much resources (a small ringbuffer?), and should not influence the working of dependent systems. Having a global error handler that logs anything that's not expected helps a lot when maintaining the application.
I are Troll
|
|
|
|
|
|
_beauw_ wrote: Logging is I/O, which is a failure-prone and time-consuming category of operation.Consider what happens if I attempt to log inside of a deeply nested loop;
I wouldn't expect a lot of unexpected exceptions in a deeply-nested loop.
_beauw_ wrote: There are .NET applications that control, or at least influence, real-time machinery.
.NET isn't recommended for time-critical operations, but how many exceptions could the app raise per 50ms?
_beauw_ wrote: There are .NET programs that guide stock traders in real-time. Entering into an I/O routine is not always an acceptable response to failure in such environments
I'm not talking about logging those exceptions that you handle locally, but those that you didn't expect and that don't get handled. There shouldn't be too many of those, and you wouldn't want to swallow those. Wouldn't want to ignore an divide by zero and price those stocks at "no worth"
I are Troll
|
|
|
|
|
try{} catch{} blocks should be use only when you need it. Else there will be a performance issue. It is not recommended to write try catch block for the whole code of any method. Where you expect to be a codeflaw, where exception may come just put your try catch there. Don't try to use generic exception in all the case. If you know some specific exception that may come, only catch those explicitly.
Don't forget to Click on [Vote] and [Good Answer] on the posts that helped you.
Regards - Kunal Chowdhury | Software Developer | Chennai | India | My Blog | My Tweets | Silverlight Tutorial
|
|
|
|
|
What you don't see, can't hurt you... It'll only hurt the guy who has to fix it.
|
|
|
|
|
Kevin Drzycimski wrote: they are world market leader
Whatever sells!
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.
|
|
|
|
|
Sounds familar
Perhaps you should add at least some tracing to your methods like this one
Then your code would be transparent to exceptions but you can still see what exceptions did flow through your code without becoming much slower.
public void Demo_Show_Leaving_Trace_With_Exception()
{
TracerConfig.Reset("console");
SomeMethod();
}
void SomeMethod()
{
using (Tracer t = new Tracer(myType, "SomeMethod"))
{
SomeOtherMethod();
}
}
private void SomeOtherMethod()
{
using (Tracer t = new Tracer(myType, "SomeOtherMethod"))
{
FaultyMethod();
}
}
private void FaultyMethod()
{
throw new NotImplementedException("Hi this a fault");
}
The output would look the like this:
18:57:46.665 03064/05180 <{{ > ApiChange.IntegrationTests.Diagnostics.TracingTests.SomeMethod
18:57:46.668 03064/05180 <{{ > ApiChange.IntegrationTests.Diagnostics.TracingTests.SomeOtherMethod
18:57:46.670 03064/05180 < }}< ApiChange.IntegrationTests.Diagnostics.TracingTests.SomeOtherMethod Exception thrown: System.NotImplementedException: Hi this a fault
at ApiChange.IntegrationTests.Diagnostics.TracingTests.FaultyMethod()
at ApiChange.IntegrationTests.Diagnostics.TracingTests.SomeOtherMethod()
at ApiChange.IntegrationTests.Diagnostics.TracingTests.SomeMethod()
at ApiChange.IntegrationTests.Diagnostics.TracingTests.Demo_Show_Leaving_Trace_With_Exception()
18:57:46.670 03064/05180 < }}< ApiChange.IntegrationTests.Diagnostics.TracingTests.SomeOtherMethod Duration 2ms
18:57:46.689 03064/05180 < }}< ApiChange.IntegrationTests.Diagnostics.TracingTests.SomeMethod Duration 24ms
That is a great time saver to find out where some exception did come from without the need to type try/catch(Exception ex) { LogException(ex);throw; } in many methods to find out where some exception did go through.
Yours,
Alois Kraus
|
|
|
|