where to put try catch block!

[Hussam Fattahi]

thanks for reply

[Lost User]

Hussam Fattahi wrote:

i need to handle in the function that calls save

That's fine, I was only offering suggestions based on your original post. It all comes down to knowing what your program is doing and how it needs to react to exceptions. Only you can really decide where is the best place, based on your understanding of the code.

txtspeak is the realm of 9 year old children, not developers. Christian Graus

[Keith Barrow]

You shouldn't do this:

catch (Exception ex)
{
MessageBox.Show(ex.Message);
}

unless you have a very good reason (e.g. this is a top-level exception handler). It is considered bad practise, you should catch known exception types, the code you have will "hide" unexpected exceptions (from testing etc).

Dalek Dave: There are many words that some find offensive, Homosexuality, Alcoholism, Religion, Visual Basic, Manchester United, Butter. Pete o'Hanlon: If it wasn't insulting tools, I'd say you were dumber than a bag of spanners.

[Hussam Fattahi]

thanks, your help is greetly appreciated

[DaveyM69]

I mean if the calling code will be able to continue regardless of specific exceptions then it's safe to catch these inside the save.

Dave

If this helped, please vote & accept answer!

Binging is like googling, it just feels dirtier. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)

[Hussam Fattahi]

i thought exception hiding is doing like this

catch (Exception ex)
{

}

and i'm not sure what specific exception will happen so i used the general exception thanks

[Abhinav S]

An approach could be to put the SQLException within the Save() method and the general exception outside - that way SQLExceptions are caught in the Save method and anything else outside.

Me, I'm dishonest. And a dishonest man you can always trust to be dishonest.
Honestly. It's the honest ones you want to watch out for...

[Hussam Fattahi]

thanks for clarification

[Lost User]

Hussam Fattahi wrote:

the problem is that many exceptions are expected and returning a bool value is not enought to descripe what error has been caught, so i need to handle in the function that calls save

There is (probably) more than one place where you "save" data. Some things can be handled locally; you might want to handle a "reconnect" to the database and execute the query again. That's the thing that you should catch. All other things should be allowed to pass by. You'd want two things to happen when an exception occurs; the user needs to know, and someone might be interested in the details of the exception later on. First things first, the user needs to be informed that something went wrong. That's where the general error-handler comes in, it's a special event that traps all unhandled exceptions. From there you can show a message - without a stacktrace, explaining what went wrong in layman-terms, and explaining what countermeasures can be taken. This way, the user gets a "Disk Full" message, without every programmer checking each method individually and displaying their own windows. It's quite easy to display a helpfull message for the most common ones and to redirect the user to a helpfull webpage. You'd probably want to log all the exceptions that you didn't handle; these should be treated as bugs. Log4Net could help you out there :)

I are Troll :suss:

[Kevin McFarlane]

Hussam Fattahi wrote:

i thought exception hiding is doing like this

Have a study of this: Design Guidelines for Exceptions[^]

Kevin

[PIEBALDconsult]

In the example given, the second way is probably better -- I wouldn't want to call your Save method from a Windows Service and have it try to pop up a message.