Click here to Skip to main content
15,881,852 members

Comments by Eric Lynch (Top 150 by date)

Eric Lynch 3-Jan-19 16:56pm View    
Sorry, I am a bit confused about your goals. I think you may be misunderstanding a few different concepts.

In your reply, you indicate an expectation for your method to return "a false result". Currently, your method cannot return any result, it is of type "void". If you want it to return a true/false result, you need to change its datatype to "bool". Though, based on the remainder of your sentence and your code, it seems unlikely that this is actually your intent.

Next, you indicate that you want to "return to the catch". Perhaps, you're using imprecise terminology, but this is not exactly how a "catch" works.

In the "have tried" section of your question, if any error (exception) were to occur in the "try" block, you would stop executing the code in that "try" block.

Instead, at that point, you would begin executing the first line of code contained in the "catch" block. Since, you currently have no code in that "catch" block, you would do nothing. Effectively, you would discard (ignore) the exception. You would then continue to the next line of code after the "catch" block.

Since you have no code after the "catch" block, you would then return nothing (void) from the "Adding" method.

While I am fairly certain this is not what you intend, I am less clear on what you do intend.

Rather than replying to my comment, I again you suggest you click "Improve Question" and edit your question to add more detail.

You need to be specific about at least two things:
1) What EXACTLY do you expect/want to happen if the code in the "try" block succeeds?
2) What EXACTLY do you expect/want to happen if the code in the "try" block fails? This is the code you want to put in the "catch" block.

Currently, in failure, you do nothing. Also, in either success or failure, you return nothing (void) from the "Adding" method.

Keep in mind that your code may fail at almost any line within the "try" block. For example, it might fail during your SQL query, or during your call to FonkA, or during your call to DeleteNonCorrectAdd. Any of these failures, would result in the code "skipping" to the first line of code in your "catch" block.
Eric Lynch 3-Jan-19 15:17pm View    
Typically, if you have a catch block, you should DO something with the exception. There are many possible actions you can take. Some common options include logging the text of the exception, re-trying the operation (for more specific exceptions like timeout), and returning an indication that the operation failed. It is seldom a good idea to simply discard the exception (as your "have tried" code would do).

It might help if you improve your question to describe your problem a little bit better. What were your expectations from the code you tried? How did the results you observed fail to meet those expectations? Its unclear from your current question if you are simply struggling to understand try/catch or you have some specific, desired outcome that you are having trouble implementing.
Eric Lynch 21-Nov-18 6:51am View    
You may want to consider clicking "Improve question" and sharing the actual text of the exception. Beyond simply letting you know that "something" has gone wrong, the text of the exception describes that "something" and can provide clues for fixing it.
Eric Lynch 20-Nov-18 8:52am View    
FWIW, here is the similar code I experimented with (which works fine). I also tried almost everything I could think of to make it fail in a similar fashion (without success).

using System;
using System.Data;
using System.Windows.Forms;

namespace CodeProjectQAForms
{
public partial class MainForm : Form
{
public MainForm() =>
InitializeComponent();

private int id;

private void addButton_Click(object sender, EventArgs e)
{
var table = listBox1.DataSource as DataTable;
if (table == null)
return;

table.Rows.Add((++id).ToString());
// table.Rows.Add(); // Also tried this

editButton.Enabled = removeButton.Enabled = table.Rows.Count > 0;
}

private void MainForm_Load(object sender, EventArgs e)
{
var table = new DataTable();
table.Columns.Add("name", typeof(string));

listBox1.DataSource = table;
listBox1.DisplayMember = "name";
}
}
}

Eric Lynch 20-Nov-18 8:12am View    
As to "I worrying about this being a bug"...don't worry its definitely a bug...unless you intended the exception :)

Seriously though, a lot of the suggestions were to help you fight assumptions. When you're trying to debug a confusing problem like this, assumptions are your biggest enemy.

Let me give you an example: "other parts of my code is not getting involved logically". If your code were working the way you intended, this would be a safe assumption. Regrettably, the code is not working. Something is happening that neither of us understand. Given this, you can no longer safely make that assumption.

Here's something I do know for certain...through experimentation...not assumption. I've written code, from scratch, that was as close as I could make it to yours. It did NOT have the same problem. So, what you're trying to do is absolutely possible. Something that is non-obvious in your code is causing a different behavior (the exception).

You may want to revisit my earlier suggestions without dismissing them so easily this time. If you want to solve this problem, the only assumption you can make is that you "know" nothing :) You'll need to confirm everything through observation or experimentation.

As to the meaning of a "mis-wired events"...each of the components on your forms (Button, ComboBox, ListBox, etc.) has a whole bunch of possible events (e.g. Click) that are associated (wired) to a given method (e.g. btnAdd_Click). Ideally, each event is wired to the method you intended.

Unfortunately, this is a case where the behavior is not evident in the code you have shared. I have seen cases where an event, either through human error, or project corruption becomes wired to an unintended method. This can cause some very strange behavior. You can check how events are wired by clicking on each of the components and looking at the event tab in properties.

I suggest improving your question to share all of these associations (between event and method).

This is an example of where assumptions can hurt you. You "assume" that all of your events are properly wired, but until you double-check you can't be certain.

If even one event is mis-wired, commenting out code or setting breakpoints, in all of the methods, are techniques that might have helped you to discover the problem. These same techniques can help uncover other incorrect assumptions.

There are similar reasons, gained through about three decades of experience, behind the other suggestions. I'd explain each, but feel this answer is already approaching novel length :)

Though, I will reiterate one suggestion. Please double check that code you have shared, for the form, is complete and identical to what you are actually running. I know it sounds silly, but in the past, I've tried to help someone only to MUCH later discover that we weren't debugging the same code.

One footnote...it is actually expected behavior that SelectedIndexChanged is NOT called. System.Windows.Forms.ListBox.set_SelectedIndex, which changes the index, fails. SelectedIndexChanged (past tense) is called AFTER the index changes, which never happens, because of the failure.