I'm trying to figure out if there is a way to generate standard error handlers
that "know" if the calling code has an error handler in effect (On Error Goto
<label> or On Error Resume Next) before deciding how to respond. Does anyone
know if this is possible.
16  2616 
On Sun, 06 Jun 2004 02:44:11 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:
If you tell us why you need this, perhaps we can respond better.
Short answer: yes, but you'll need to keep track of the call stack
yourself.
-Tom. I'm trying to figure out if there is a way to generate standard error handlers
that "know" if the calling code has an error handler in effect (On Error Goto
<label> or On Error Resume Next) before deciding how to respond. Does anyone
know if this is possible.
On Sat, 05 Jun 2004 20:50:17 -0700, Tom van Stiphout <to*****@no.spam.cox.net>
wrote: On Sun, 06 Jun 2004 02:44:11 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:
If you tell us why you need this, perhaps we can respond better.
Short answer: yes, but you'll need to keep track of the call stack
yourself.
-Tom.
I'm trying to figure out if there is a way to generate standard error handlers
that "know" if the calling code has an error handler in effect (On Error Goto
<label> or On Error Resume Next) before deciding how to respond. Does anyone
know if this is possible.
Basically, I'm trying to reduce the number of standard variations of error
handling code block I need to implement in an app that will run and handle
errors gracefully and appropriately in the Access run-time environment.
The conflict now, is between 2 standard cases:
1. Any code (except special cases) that will execute in response to a user
event must have an error handler that displays an error message (possibly
logging the error, etc.) and resumes at the procedure exit point.
2. Any code called by other code should, by default, re-raise the error to
calling code, adding its procedure name to the Source to show the call stack.
If you use 2 where you should use 1, the calling code may proceed on the
assumption that the called code did its job correctly, and this can be a
dangerous assumption when it didn't. Furthermore, there can be cases where a
procedure may be either case 1 or case 2 in different circumstances.
What I'm hoping to have is an error handling block that knows to display a
message and exit if no error handler is in effect in calling code, and to
re-raise the error if there is an error handler in effect in the calling code.
On Sun, 06 Jun 2004 04:56:18 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:
If you outfit every proc with a Push and a Pop function to push and
pop its name on and off the stack, and you would pass an extra
argument indicating if this proc is using an error handler or not,
then you could in an error handling block walk that stack and check
the presence or absence of an error handler.
Unfortunately, unlike the .NET environment, in Access you don't have
access to the stack, so the above is doing a similar thing the hard
way.
Personally, I don't make a distinction between case 1 and case 2, and
I "always" implement case 1.
-Tom. On Sat, 05 Jun 2004 20:50:17 -0700, Tom van Stiphout <to*****@no.spam.cox.net>
wrote:
On Sun, 06 Jun 2004 02:44:11 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:
If you tell us why you need this, perhaps we can respond better.
Short answer: yes, but you'll need to keep track of the call stack
yourself.
-Tom.
I'm trying to figure out if there is a way to generate standard error handlers
that "know" if the calling code has an error handler in effect (On Error Goto
<label> or On Error Resume Next) before deciding how to respond. Does anyone
know if this is possible.
Basically, I'm trying to reduce the number of standard variations of error
handling code block I need to implement in an app that will run and handle
errors gracefully and appropriately in the Access run-time environment.
The conflict now, is between 2 standard cases:
1. Any code (except special cases) that will execute in response to a user
event must have an error handler that displays an error message (possibly
logging the error, etc.) and resumes at the procedure exit point.
2. Any code called by other code should, by default, re-raise the error to
calling code, adding its procedure name to the Source to show the call stack.
If you use 2 where you should use 1, the calling code may proceed on the
assumption that the called code did its job correctly, and this can be a
dangerous assumption when it didn't. Furthermore, there can be cases where a
procedure may be either case 1 or case 2 in different circumstances.
What I'm hoping to have is an error handling block that knows to display a
message and exit if no error handler is in effect in calling code, and to
re-raise the error if there is an error handler in effect in the calling code.
On Sat, 05 Jun 2004 22:21:56 -0700, Tom van Stiphout <to*****@no.spam.cox.net>
wrote: On Sun, 06 Jun 2004 04:56:18 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:
If you outfit every proc with a Push and a Pop function to push and
pop its name on and off the stack, and you would pass an extra
argument indicating if this proc is using an error handler or not,
then you could in an error handling block walk that stack and check
the presence or absence of an error handler.
Unfortunately, unlike the .NET environment, in Access you don't have
access to the stack, so the above is doing a similar thing the hard
way.
Personally, I don't make a distinction between case 1 and case 2, and
I "always" implement case 1.
-Tom.
On Sat, 05 Jun 2004 20:50:17 -0700, Tom van Stiphout <to*****@no.spam.cox.net>
wrote:
On Sun, 06 Jun 2004 02:44:11 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:
If you tell us why you need this, perhaps we can respond better.
Short answer: yes, but you'll need to keep track of the call stack
yourself.
-Tom.
I'm trying to figure out if there is a way to generate standard error handlers
that "know" if the calling code has an error handler in effect (On Error Goto
<label> or On Error Resume Next) before deciding how to respond. Does anyone
know if this is possible.
Basically, I'm trying to reduce the number of standard variations of error
handling code block I need to implement in an app that will run and handle
errors gracefully and appropriately in the Access run-time environment.
The conflict now, is between 2 standard cases:
1. Any code (except special cases) that will execute in response to a user
event must have an error handler that displays an error message (possibly
logging the error, etc.) and resumes at the procedure exit point.
2. Any code called by other code should, by default, re-raise the error to
calling code, adding its procedure name to the Source to show the call stack.
If you use 2 where you should use 1, the calling code may proceed on the
assumption that the called code did its job correctly, and this can be a
dangerous assumption when it didn't. Furthermore, there can be cases where a
procedure may be either case 1 or case 2 in different circumstances.
What I'm hoping to have is an error handling block that knows to display a
message and exit if no error handler is in effect in calling code, and to
re-raise the error if there is an error handler in effect in the calling code.
Of course, what I wrote above was slightly backward. If you use case 2 when
you should use case 1, you crash out of Access. If you use case 1 when you
use case 2, the calling code can proceed thinking the called code did its job.
About 3/4 of the time, that's OK. Other times, the calling code will error
again because something it expected didn't happen, and the user now has to
click OK 2 or more times for a single error. A few other times, the
procedures could both be handling part of a transactional process (either
formally with a database transaction, informally with some sort of deletion
roll-back), and data can be left in an invalid state according to the business
rules.
I thought of custom the stack idea, but I don't know if code can always be
guaranteed to be stacked in the order of execution. For instance, a timer
event could fire while a modal form is open (though I avoid timer events when
I can). There are probably other ways this could happen that I haven't
thought of.
On Sun, 06 Jun 2004 05:53:28 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:
I'm not concerned about your Timer example. When the timer ticks, your
proc is added to the stack, the code runs and finishes, Pop is called,
the stack frame cleans up, and you're back where you were.
In all the years I have used the Push/Pop code, with additional bounds
checking added, I have never seen it fail, other than due to
programmer error (Exit Function without Pop).
-Tom. On Sat, 05 Jun 2004 22:21:56 -0700, Tom van Stiphout <to*****@no.spam.cox.net>
wrote:
On Sun, 06 Jun 2004 04:56:18 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:
If you outfit every proc with a Push and a Pop function to push and
pop its name on and off the stack, and you would pass an extra
argument indicating if this proc is using an error handler or not,
then you could in an error handling block walk that stack and check
the presence or absence of an error handler.
Unfortunately, unlike the .NET environment, in Access you don't have
access to the stack, so the above is doing a similar thing the hard
way.
Personally, I don't make a distinction between case 1 and case 2, and
I "always" implement case 1.
-Tom.
On Sat, 05 Jun 2004 20:50:17 -0700, Tom van Stiphout <to*****@no.spam.cox.net>
wrote:
On Sun, 06 Jun 2004 02:44:11 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:
If you tell us why you need this, perhaps we can respond better.
Short answer: yes, but you'll need to keep track of the call stack
yourself.
-Tom.
>I'm trying to figure out if there is a way to generate standard error handlers
>that "know" if the calling code has an error handler in effect (On Error Goto
><label> or On Error Resume Next) before deciding how to respond. Does anyone
>know if this is possible.
Basically, I'm trying to reduce the number of standard variations of error
handling code block I need to implement in an app that will run and handle
errors gracefully and appropriately in the Access run-time environment.
The conflict now, is between 2 standard cases:
1. Any code (except special cases) that will execute in response to a user
event must have an error handler that displays an error message (possibly
logging the error, etc.) and resumes at the procedure exit point.
2. Any code called by other code should, by default, re-raise the error to
calling code, adding its procedure name to the Source to show the call stack.
If you use 2 where you should use 1, the calling code may proceed on the
assumption that the called code did its job correctly, and this can be a
dangerous assumption when it didn't. Furthermore, there can be cases where a
procedure may be either case 1 or case 2 in different circumstances.
What I'm hoping to have is an error handling block that knows to display a
message and exit if no error handler is in effect in calling code, and to
re-raise the error if there is an error handler in effect in the calling code.
Of course, what I wrote above was slightly backward. If you use case 2 when
you should use case 1, you crash out of Access. If you use case 1 when you
use case 2, the calling code can proceed thinking the called code did its job.
About 3/4 of the time, that's OK. Other times, the calling code will error
again because something it expected didn't happen, and the user now has to
click OK 2 or more times for a single error. A few other times, the
procedures could both be handling part of a transactional process (either
formally with a database transaction, informally with some sort of deletion
roll-back), and data can be left in an invalid state according to the business
rules.
I thought of custom the stack idea, but I don't know if code can always be
guaranteed to be stacked in the order of execution. For instance, a timer
event could fire while a modal form is open (though I avoid timer events when
I can). There are probably other ways this could happen that I haven't
thought of.
On Sun, 06 Jun 2004 10:17:29 -0700, Tom van Stiphout <to*****@no.spam.cox.net>
wrote: On Sun, 06 Jun 2004 05:53:28 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:
I'm not concerned about your Timer example. When the timer ticks, your
proc is added to the stack, the code runs and finishes, Pop is called,
the stack frame cleans up, and you're back where you were.
But the whole point of the stack is that it's supposed to track whether the
calling code has an error handler. The timer event will be on the stack,
possibly after another procedure with an error handler, wit the timer event
was not called by that code. Thus, the error handler will think it should
re-raise the error, and crash out of Access when it does. I'm a little
concerned about this, but more concerned about other types of out-of-order
events I might not have considered.
In all the years I have used the Push/Pop code, with additional bounds
checking added, I have never seen it fail, other than due to
programmer error (Exit Function without Pop).
So perhaps, the timer is the only possible case?
-Tom.
On Sat, 05 Jun 2004 22:21:56 -0700, Tom van Stiphout <to*****@no.spam.cox.net>
wrote:
On Sun, 06 Jun 2004 04:56:18 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:
If you outfit every proc with a Push and a Pop function to push and
pop its name on and off the stack, and you would pass an extra
argument indicating if this proc is using an error handler or not,
then you could in an error handling block walk that stack and check
the presence or absence of an error handler.
Unfortunately, unlike the .NET environment, in Access you don't have
access to the stack, so the above is doing a similar thing the hard
way.
Personally, I don't make a distinction between case 1 and case 2, and
I "always" implement case 1.
-Tom.
On Sat, 05 Jun 2004 20:50:17 -0700, Tom van Stiphout <to*****@no.spam.cox.net>
wrote:
>On Sun, 06 Jun 2004 02:44:11 GMT, Steve Jorgensen
><no****@nospam.nospam> wrote:
>
>If you tell us why you need this, perhaps we can respond better.
>
>Short answer: yes, but you'll need to keep track of the call stack
>yourself.
>
>-Tom.
>
>
>>I'm trying to figure out if there is a way to generate standard error handlers
>>that "know" if the calling code has an error handler in effect (On Error Goto
>><label> or On Error Resume Next) before deciding how to respond. Does anyone
>>know if this is possible.
Basically, I'm trying to reduce the number of standard variations of error
handling code block I need to implement in an app that will run and handle
errors gracefully and appropriately in the Access run-time environment.
The conflict now, is between 2 standard cases:
1. Any code (except special cases) that will execute in response to a user
event must have an error handler that displays an error message (possibly
logging the error, etc.) and resumes at the procedure exit point.
2. Any code called by other code should, by default, re-raise the error to
calling code, adding its procedure name to the Source to show the call stack.
If you use 2 where you should use 1, the calling code may proceed on the
assumption that the called code did its job correctly, and this can be a
dangerous assumption when it didn't. Furthermore, there can be cases where a
procedure may be either case 1 or case 2 in different circumstances.
What I'm hoping to have is an error handling block that knows to display a
message and exit if no error handler is in effect in calling code, and to
re-raise the error if there is an error handler in effect in the calling code.
Of course, what I wrote above was slightly backward. If you use case 2 when
you should use case 1, you crash out of Access. If you use case 1 when you
use case 2, the calling code can proceed thinking the called code did its job.
About 3/4 of the time, that's OK. Other times, the calling code will error
again because something it expected didn't happen, and the user now has to
click OK 2 or more times for a single error. A few other times, the
procedures could both be handling part of a transactional process (either
formally with a database transaction, informally with some sort of deletion
roll-back), and data can be left in an invalid state according to the business
rules.
I thought of custom the stack idea, but I don't know if code can always be
guaranteed to be stacked in the order of execution. For instance, a timer
event could fire while a modal form is open (though I avoid timer events when
I can). There are probably other ways this could happen that I haven't
thought of.
> >I'm not concerned about your Timer example. When the timer ticks, your proc is added to the stack, the code runs and finishes, Pop is called,
the stack frame cleans up, and you're back where you were.
But the whole point of the stack is that it's supposed to track whether
the calling code has an error handler. The timer event will be on the stack,
possibly after another procedure with an error handler, wit the timer
event was not called by that code. Thus, the error handler will think it should
re-raise the error, and crash out of Access when it does. I'm a little
concerned about this, but more concerned about other types of out-of-order
events I might not have considered.
????
If on entry your Timer proc does the appropriate push/pop then you will know
where you are. Access/VBA are not multithreaded so you can just go with
that.
In all the years I have used the Push/Pop code, with additional bounds
checking added, I have never seen it fail, other than due to
programmer error (Exit Function without Pop).
So perhaps, the timer is the only possible case?
No, things will work there too as long as you recognize the limitations?
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies
This posting is provided "AS IS" with
no warranties, and confers no rights.
On Sun, 6 Jun 2004 16:19:55 -0700, "Michael \(michka\) Kaplan [MS]"
<mi*****@online.microsoft.com> wrote: >I'm not concerned about your Timer example. When the timer ticks, your
>proc is added to the stack, the code runs and finishes, Pop is called,
>the stack frame cleans up, and you're back where you were. But the whole point of the stack is that it's supposed to track whetherthe calling code has an error handler. The timer event will be on the stack,
possibly after another procedure with an error handler, wit the timer
event was not called by that code. Thus, the error handler will think it should
re-raise the error, and crash out of Access when it does. I'm a little
concerned about this, but more concerned about other types of out-of-order
events I might not have considered.
????
If on entry your Timer proc does the appropriate push/pop then you will know
where you are. Access/VBA are not multithreaded so you can just go with
that.
The order of calling and returning will be correct, but since the timer event
is called by Access, not by the previously called code, if it raises an error,
the previously called code's hanlder will not be invoked. Access will close.
Am I missing something?
>In all the years I have used the Push/Pop code, with additional bounds
>checking added, I have never seen it fail, other than due to
>programmer error (Exit Function without Pop).
So perhaps, the timer is the only possible case?
No, things will work there too as long as you recognize the limitations?
Well, whether I'm right about the timer event issue or not, it's a special
case that hardly occurs, and I know what to do there - so I guess the custom
call stack idea is sounding solid enough. I'll just go with that.
Thanks for the help all,
- Steve J.
On Sun, 6 Jun 2004 16:19:55 -0700, "Michael \(michka\) Kaplan [MS]"
<mi*****@online.microsoft.com> wrote:
.... ????
If on entry your Timer proc does the appropriate push/pop then you will know
where you are. Access/VBA are not multithreaded so you can just go with
that.
I just realized what I was thinking of that you might not have been. Access
VBA is not technically multi-threaded, but there are times, such as when a
dialog box is open when timer events (and other events) can fire and be
processed when they were not called by the running code that's waiting for the
dialog. The calling order does not mirror the internal the call stack in such
cases.
"Steve Jorgensen" <no****@nospam.nospam> wrote... The order of calling and returning will be correct, but since the timer
event is called by Access, not by the previously called code, if it raises an
error, the previously called code's hanlder will not be invoked. Access will
close. Am I missing something?
Since you will have an error handler in your Timer event proc, it will not
bubnble any further up.
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies
This posting is provided "AS IS" with
no warranties, and confers no rights.
H vae you looked at the call stack in such instances while debugging? It
handles the issue quite nicely; so can you.
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies
This posting is provided "AS IS" with
no warranties, and confers no rights.
"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:jv********************************@4ax.com... On Sun, 6 Jun 2004 16:19:55 -0700, "Michael \(michka\) Kaplan [MS]"
<mi*****@online.microsoft.com> wrote:
...????
If on entry your Timer proc does the appropriate push/pop then you will
knowwhere you are. Access/VBA are not multithreaded so you can just go with
that.
I just realized what I was thinking of that you might not have been.
Access VBA is not technically multi-threaded, but there are times, such as when a
dialog box is open when timer events (and other events) can fire and be
processed when they were not called by the running code that's waiting for
the dialog. The calling order does not mirror the internal the call stack in
such cases.
On Sun, 6 Jun 2004 20:16:43 -0700, "Michael \(michka\) Kaplan [MS]"
<mi*****@online.microsoft.com> wrote: "Steve Jorgensen" <no****@nospam.nospam> wrote...
The order of calling and returning will be correct, but since the timer
event is called by Access, not by the previously called code, if it raises an
error, the previously called code's hanlder will not be invoked. Access will
close. Am I missing something?
Since you will have an error handler in your Timer event proc, it will not
bubnble any further up.
Ah, but there's the rub. The whole idea I was trying to come up with is a
generic error handler that can tell if it was called from another procedure
that has an error handler or not.
I never worried about this when it was just me maintaining my code, but I'm
working with someone else on a project who doesn't feel comfortable that he
understands my logic on which procedures need what kind of error handling.
"Steve Jorgensen" <no****@nospam.nospam> wrote... Ah, but there's the rub. The whole idea I was trying to come up with is a
generic error handler that can tell if it was called from another
procedure that has an error handler or not.
That is the whole idea? Darn, because thats a lousy idea even when its only
part of the idea.
I never worried about this when it was just me maintaining my code, but
I'm working with someone else on a project who doesn't feel comfortable that
he understands my logic on which procedures need what kind of error handling.
So always have error handlers in every event proc, and then you are covered.
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies
This posting is provided "AS IS" with
no warranties, and confers no rights.
>> I never worried about this when it was just me maintaining my code, but I'm working with someone else on a project who doesn't feel comfortable that he
understands my logic on which procedures need what kind of error handling.
So always have error handlers in every event proc, and then you are covered.
Now, the thread has gone full circle. Putting error handling in every
procedure is fine, but what goes into each error handler still depends what
the context of the procedure will be. If the calling procedure should stop if
the called code fails, the called code should re-raise the error - or just not
handle it if no clean-up is neeeded and if we weren't talking about putting
error handlers everywhere (though adding the proc name to Source is nice).
If a procedure is always invoked by a user action, it should report the error
to the user and do a normal procedure exit. That's how I always write my
error handlers, and that always works as advertised, but since the new code
owner doesn't get this, I was trying to see if I could get the code to be
intelligent enough to do it automatically, and just eliminate this as a
maintenance issue for the programmer.
Not really -- in the case of event code you can just about always assume
that it is Access that is "on the stack" triggering the event, and just trap
the errors yourself. All you need to do is use your brain about the event
itself to decide what to do..... and add comments for the maintenance
programmer.
Thinking about them is great, but all the time you are spending trying to
make the code automatic would probably be better served enhancing comments
enough so that when they are debugging they are not lost.
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies
This posting is provided "AS IS" with
no warranties, and confers no rights.
"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:07********************************@4ax.com... I never worried about this when it was just me maintaining my code, but
I'm working with someone else on a project who doesn't feel comfortable
that he understands my logic on which procedures need what kind of error
handling.So always have error handlers in every event proc, and then you are
covered.
Now, the thread has gone full circle. Putting error handling in every
procedure is fine, but what goes into each error handler still depends
what the context of the procedure will be. If the calling procedure should
stop if the called code fails, the called code should re-raise the error - or just
not handle it if no clean-up is neeeded and if we weren't talking about
putting error handlers everywhere (though adding the proc name to Source is nice).
If a procedure is always invoked by a user action, it should report the
error to the user and do a normal procedure exit. That's how I always write my
error handlers, and that always works as advertised, but since the new
code owner doesn't get this, I was trying to see if I could get the code to be
intelligent enough to do it automatically, and just eliminate this as a
maintenance issue for the programmer.
On Mon, 7 Jun 2004 03:32:13 -0700, "Michael \(michka\) Kaplan [MS]"
<mi*****@online.microsoft.com> wrote: Not really -- in the case of event code you can just about always assume
that it is Access that is "on the stack" triggering the event, and just trap
the errors yourself. All you need to do is use your brain about the event
itself to decide what to do..... and add comments for the maintenance
programmer.
Uh - yeah. That's pretty much what I said to the other programmer.
Thinking about them is great, but all the time you are spending trying to
make the code automatic would probably be better served enhancing comments
enough so that when they are debugging they are not lost.
Well, it's always worth taking some time to see if concerns can be moved
completely out of the programmer's way because it saves time and reduces bugs
later - on future projects as well. If there's no way to do it, there's no
way to do it, but I like to go ahead and try to explore the options. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: John Roth |
last post by:
PEP 263 is marked finished in the PEP index, however
I haven't seen the specified Phase 2 in the list of changes
for 2.4 which is when I expected it.
Did phase 2 get cancelled, or is it just not...
|
by: tabonni |
last post by:
I want to check each button groups and save the checked value into a 2
dimensional array. But, it doesn't work. Could anyone tell me what's
wrong with my code. My code is as follow:
<html>...
|
by: collincm |
last post by:
Hi,
I am trying to optimize a table for inserts. Half of the timeron cost is in
the FK lookup!
These tables for example
CREATE TABLE FOO2(
FOO2_ID INTEGER NOT NULL CONSTRAINT FOO2_PK...
|
by: V_S_H_Satish |
last post by:
Hai Friends
Quite a long time back i ask these questions but everybody send me some
snapshot and functions names but i need select statements for the
following stuff pls help me in this
1....
|
by: John Salerno |
last post by:
My code is below. The main focus would be on the OnStart method. I want
to make sure that a positive integer is entered in the input box. At
first I tried an if/else clause, then switched to...
|
by: Chandra |
last post by:
How do I programmatically (javascript) check if link is valid in html?
|
by: polycom |
last post by:
Hi,
I am coding a mysql health check script. The logic is to execute the commands (only once)show status,show slave status,show variables and fetch the variable name and value in a hash refer or...
|
by: Edwin.Madari |
last post by:
updated creature running in its own thread will get you started. try it foryourself, change sleep times per your need.
import os, sys, threading, time
class Creature:
def __init__(self,...
|
by: alex21 |
last post by:
I'm trying to detect the http status number such as (401 Unauthorized) from a 'WebException' when a WebClient in my code fails.
Public Function DataSources_ValidURL() As Boolean
Dim...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
